We Keep Coding

Can I use Gmail API send email without Google Workspace (or Service accounts)?

I want to use Gmail API to send email in JAVA,and all information I fond told me to create a Service accounts and connect with Google Workspace. But I don't have a Google Workspace account also can't register one,so the question is:
1.Can I send email without Google Workspace?
2.Can I just Add 'type' into Client ID.json to make it work like Service accounts.json?

Can I send email without Google Workspace?
Yes you can use gmail api without workspace you will just need to use Oauth2 rather than a service account and authorize a user.
Oauth2 requires that a user consent to the access to their google account. A user will need to authorize your code at least once.
Where as service accounts allow you to preauthroize access defined using domain wide delegation within a google workspace account. So no user interaction would be required.
Can I just Add 'type' into Client ID.json to make it work like Service accounts.json?
No the code is different depending upon the type of client you have created. If you create a web client then you need to use code designed for a web client. If you create installed client credentials then you need to use the code for an installed client.
The following sample Java quickstart is designed for an installed app. It will open the browser consent window on the machine the code is running on.

Authenticate to autodesk

We are developing a Java application that is supposed to show models from users store.
initially, I'm trying to allow users to login using their autodesk account, and check if they are entitled to access my app.
I couldn't find any good example to show how it is done, I just want to confirm that what I will be doing is the recommended thing or if there is better options.
First, on app start, I will show an embedded webbrowser that will open
"https://developer.api.autodesk.com/authentication/v1/authorize?response_type=code&client_id=XXX&redirect_uri=XXX&scope=XXX"
the app will get the url from our server (so not saved locally) and the call back is pointing to an api on our server. then as user login and consent, will get the code from the url, close the login dialog and continue to get the bearer token using plain rest apis to /authentication/v1/gettoken.
As I said, not 100% sure if this is approved way or not or even if it is doable or not. so thought to check before we implement it.
After that I will just use rest apis to browse and get the model.
any thoughts or complains ?
Thanks in advance

Rest assured that the workflow being proposed here is actually orthodoxical and well “approved” by our official tutorials:
https://forge.autodesk.com/en/docs/oauth/v2/tutorials/get-3-legged-token/
http://learnforge.autodesk.io/#/oauth/3legged/
Unfortunaly the code sample for that bit is in node and we are still working on a Java equilvalent
Some of our endpoints require 3-legged oauth to access personal data - see here for an example and you can always refer to the authentication context section of each endpoint for the oauth flow required.

Google Drive API Access my own account

I wish to run a simple process on my server/laptop that will upload files to my google drive on a daily basis, once a day. I don't wish to share this, allow other users to use it etc.
All examples I find seem to involve browsing to an address to gain permission from the user (me) and then getting an auth code etc and proceding
ref: Java quickstart
Is there a way/example to do this without need of a browser, getting permission getting unique auth code each time as I only want to do this for my account?
Can I use a bash script with CURL commands rather than having to use Java?

Yes. See How do I authorise an app (web or installed) without user intervention? (canonical ?)
Yes. It becomes a complicated script if your file is large and you are doing resumable uploads, but for small files it's perfectly feasible. You'll need to play around a bit to get the correct encoding, multipart mime body, mime type and content size, but it's all eminently doable. You'll start by calling Google's auth api with your stored refresh token to get an access token. Then you'll set that access token into an Authorization bearer header as part of your content upload call.

Dropbox authentication in Android app using previously generated token

I'm developing an android app, just for myself really, to learn android and also to make something useful for myself. The app is sort of an extension to a desktop application that I wrote. One of the things that the desktop app does is upload some textual data and images to a Dropbox account that I created just for this purpose.
The android app offers a pared down implementation of the desktop app, so that I can get some of the same functionality on-the-go. So, when the android app starts up, it checks the dropbox account and downloads any new data that it doesn't already have.
For the desktop app (Python), I just did an authentication manually by hitting the dropbox auth endpoint with my dropbox app key (in a browser) and then using the 'code' I got from that to finally get an access token. So I've hardcoded that token into my desktop app, and it bypasses the oAuth process and just uses the token for authentication. It's uploading data just fine.
But whereas the Python Dropbox API allows me to do that, I'm not sure how to do that with the android dropbox API. I've been browsing through the classes in the JavaDocs for the API, but it seems that I have to go through the oAuth process to get an AccessTokenPair for authentication (which seems to consist of a key and a secret). Can I not just provide the same token I use in the desktop app to some object (a DropboxAPI instance, maybe) to get authenticated?
I realize now that this kind of use for Dropbox is probably not very intuitive, but I'm invested now so I'd like to make it work if I can.
EDIT:
It seems that you can avoid having to go through the oAuth process if you have an AccessTokenPair (or it's values) saved from a previous authentication session. It looks like the AccessTokenPair is just wrapper for two strings: key and secret. So I suppose my question is now, what are these two values. I have an access token, which is a ~64 character string that my desktop app is using successfully for authentication. Can I use this to create an AccessTokenPair object, and if I can, is it a key or a secret and what I'm I missing?
SOLUTION:
As Smarx has said, the problem is that the Android and iOS Dropbox clients use oAuth1 whereas the Python, Ruby, PHP and Java clients use oAuth2. So, I actually ended up just following the oAuth1 process for Android, logging the resulting access key and secret and then hardcoding those for future use to bypass the oAuth process. It seems to be working fine.

Are you using the Core API or Sync API?
In the case of the Sync API, I think there's no easy way to use a token you already have.
In the case of the Core API, I think you can do it, but I believe the Android Core SDK still uses OAuth 1, and my guess is that you have an OAuth 2 token.

the oauth1 API seems to be deprecated. Looks like this is certainly a deficiency, because I am trying the same thing and it is completely broken basically, I can authenticate and then generate an oauth2 token which is stored but using it I couldn't logon again, unless I rebuild the API object again.
EDIT: sorry about the multiple comments below, I do not seem to have the privilege of being able to delete my own comments.
EDIT: yay now I can delete my own comments so answer is below:
//first logon - get the token and save it to shared prefs
if (emboDBApi.getSession().authenticationSuccessful()) {
try {
emboDBApi.getSession().finishAuthentication();
String accessToken = emboDBApi.getSession().getOAuth2AccessToken();
SharedPreferences.Editor editor = prefs.edit();
editor.putString("emboDBAccessToken", accessToken); editor.apply();
}
catch (IllegalStateException e) { Log.v(TAG, "Error authenticating", e);
}
}
//for subsequent logons use the saved token if it exists and then create a
auth session from that.
AndroidAuthSession newSession = new AndroidAuthSession(Constants.KEY_PAIR,
prefs.getString("emboDBAccessToken", ""));
emboDBApi = new DropboxAPI<AndroidAuthSession>(newSession);

Google App Engine : Read from Google Cloud Storage

I have a Flex/Java application on Google App Engine and all I want is to load large images from Google Cloud Storage using URLRequest in Flex. I'm sure this is simple but I can't get it to work. I will manually upload the images using the Google APIs Console so I don't need to write anything from the App. The images can not be public.
I'm not 100% sure how to access the file so this may be the problem. I tried these:
"/gs/mybucket/myimage.jpg" : not found
"/mybucket/myimage.jpg" : not found
"http://commondatastorage.googleapis.com/mybucket/myimage.jpg" : denied
I added myappid#appspot.gserviceaccount.com in the Team tab in Google APIs Console with Can View permission and I used GSUtil to get and set ACLs on both mybucket and myimage.jpg to add a READ permission for myappid#appspot.gserviceaccount.com but that didn't help.
What am I doing wrong?

I'm not really sure how flex works or how it is trying to access the blobs.
However, if you want to respond to a http request with the content of a Google Storage object then you can use the serve method.
https://developers.google.com/appengine/docs/java/blobstore/overview#Serving_a_Blob

Are you authorizing the URLRequest call with an OAuth token? If not, then even though the request is initiated from an app engine app, it'll look to Google Cloud Storage like an unauthenticated, public read. I don't know if flex has a trace option but if there's a way to examine the request details, I'd check to see if you're setting up the proper authentication.
If it turns out to be too difficult to get flex to play nicely with OAuth, you could also use signed URLs (a.k.a. query string authenticated URLs). This gives you the ability to create a URL with a special signature that implicitly conveys your authorization but only people with that link can access the object. The object's ACL can be be set to disallow public access but your signed URLs will be able to read the object. You can also time limit a signed URLs, if you like. Here's the documentation on how to use this technique.