I'm building a webapp where a user can Authorize via OAuth2 and choose/upload files from their own Drive for later use. Essentially we're just storing the file ID and using the API to access them later. Everything is working fine when I use .setAuthUser() and require users to be logged in independent of our app, but when we use .setOAuthToken() instead only the file picker works — the DocsUploadView panel returns an "undefined" error.
This behavior is consistent across Firefox/Chrome/Safari and with or without a current user login. It's always able to see files, never able to upload them. We are requesting full drive scope but even with that we're seeing errors.
For now we're just using setAuthUser as a workaround but this causes extra steps and a few problems when a user isn't logged in. Is it possible to use setOAuthToken with DocsUploadView?
The picker builder code I'm using is below, with IDs and tokens in the same format I'm using but altered for security.
Thanks!
var view = new google.picker.View(google.picker.ViewId.DOCS);
var uploadview = new google.picker.DocsUploadView();
var picker = new google.picker.PickerBuilder()
.enableFeature(google.picker.Feature.MINE_ONLY)
.disableFeature(google.picker.Feature.NAV_HIDDEN)
.disableFeature(google.picker.Feature.MULTISELECT_ENABLED)
.setAppId('987654321098')
.setOAuthToken('ya31.AIER6DRhxRgRsT0SoGPoaxPMhDd0n3OHKj43SJaG5kFndZ52')
.addView(uploadview)
.addView(view)
.setCallback(pickerCallback)
.build();
picker.setVisible(true);
[cross-posted at: https://groups.google.com/d/topic/google-picker-api/p9whgDscUrQ/discussion]
The Picker API doesn't currently support uploads using OAuth tokens. I filed an internal feature request for this to be implemented, but for the moment you should keep relying on your workaround.
This even SOUNDS stupid, but what about order of execution in the chaining?
.addView(uploadview)
.addView(view)
becomes
.addView(view)
.addView(uploadview)
Another thing I might suggest here is to enable multi_select on the picker
enableFeature(google.picker.Feature.NAV_HIDDEN)
enableFeature(google.picker.Feature.MULTISELECT_ENABLED)
, just to test that there's not a bug in dependency on either of those features.
Related
I am creating some google app scripts for my company to use to generate random tests for employee training. I already have the basic scripts written to grab a list of questions from a google sheet, randomize them, grab the first 10 questions, etc. That all works fine. I decided it might be better to re-do the whole thing using a UiApp instead of just separate scripts. That is where the problem comes in. I did a simple bare bones UiApp to test with, published it and tried to hit the URL and that's where I encounter this error. I searched for this error and all I could find was some discussion about this being part of google apps premiere(which should have been folded into regular google apps around 2010). I've been staring at this so long I've frustrated myself. It should be something very simple and yet it's refusing to work. I'm assuming I am doing something wrong at a basic level but I've reached the point where my brain refuses to see it.
Here is the basic script I started with:
function doGet(e) {
var app = UiApp.createApplication();
var mainPanel = app.createVerticalPanel().setId('mainPanel');
mainPanel.add(app.createLabel('test'));
return app;
}
I save it, publish it and go to the URL and that's when I get the above error message. I know it's something simple but I've reached the point of frustration and simply can't see it.
Update: to reflect comments
Another possibility for WebApps not updating is not publishing a new version and only checking the exec URL. For instant changes to the code, always check the dev URL. The exec will only change after saving a version in Manage Versions and re-publishing the app.
First Answer:
I think your question title says it all.
UIApp is not defined, but Class is UiApp. JS is case sensitive. I copied and pasted the code exactly as it is in your question and received no errors. I did have to add one line to make the label show up.
function doGet(e) {
var app = UiApp.createApplication();
var mainPanel = app.createVerticalPanel().setId('mainPanel');
mainPanel.add(app.createLabel('test'));
app.add(mainPanel); // <-- I added this line to see the label
return app;
}
I am working with realtime API and I am making use of realtime-client-utils.
Using existing code, I am creating realtime files with this method:
createRealtimeFile = function(title, callback) {
gapi.client.load('drive', 'v2', function() {
gapi.client.drive.files.insert({
'resource': {
mimeType: rtclient.REALTIME_MIMETYPE,
title: title
}
}).execute(callback);
});
}
and then I am trying to open files with this picker:
var popupOpen = function () {
var token = gapi.auth.getToken().access_token;
var view = new google.picker.View(google.picker.ViewId.DOCS);
view.setMimeTypes(rtclient.REALTIME_MIMETYPE+ "."+realTimeOptions.appId);
var picker = new google.picker.PickerBuilder()
.enableFeature(google.picker.Feature.NAV_HIDDEN)
.setAppId(realTimeOptions.appId)
.setOAuthToken(token)
.addView(view)
.addView(new google.picker.DocsUploadView())
.setCallback(pickerCallback)
.build();
picker.setVisible(true);
};
Although if I use the setMimeTypes, no documents are found. If I remove that filter, my documents appear normally(along with every time of document in the drive). THe mime type I am using is the default one:
rtclient.REALTIME_MIMETYPE = 'application/vnd.google-apps.drive-sdk';
I am adding the appID as this is how its done on realtime-playground. I also tried without the "." or the appID but no documents are found.
Any suggestions about how to fix the filter ?
You should look for mimeType you created with.
You created your file with mimeType rtclient.REALTIME_MIMETYPE and you're looking for files with mimeType rtclient.REALTIME_MIMETYPE+ "."+realTimeOptions.appId That is the reason why you're not getting any files.
Change filepicker code to:
view.setMimeTypes(rtclient.REALTIME_MIMETYPE);
And make sure you change
rtclient.REALTIME_MIMETYPE = 'application/{{YOURE_CUSTOM_MIMETYPE}}';
to avoid collision with other apps.
Found the answer on an android forum. I had to create files with this mimeType:
REALTIME_MIMETYPE = 'application/vnd.google-apps.drive-sdk.'+appID;
and use same mimeType on view :
view.setMimeTypes(REALTIME_MIMETYPE);
Short answer: correct your appID. It is the first part of your CLIENT-ID. That is, if your client-id is 1088706429537-4oqhqr7o826ditbok23sll1rund1jim1.apps.googleusercontent.com, your APP_ID is 1088706429537. I initially confused it with the project-id and had your problem.
I started new answer because all accepted ones are wrong since they disregard the main issue. Might be they are right advising to change the mime-type to something completely custom. Yet, the most popular answer says that
You created your file with mimeType rtclient.REALTIME_MIMETYPE and
you're looking for files with mimeType rtclient.REALTIME_MIMETYPE+
"."+realTimeOptions.appId
This is seems natural but wrong fact. The topic author is right reproducing the demos. Google demos seem to do exactly that: they create application/vnd.google-apps.drive-sdk file and look for appid-expanded ones. This is correct actually because whenever you create a REALTIME_MIMETYPE=application/vnd.google-apps.drive-sdk file, google drive silently fixes file type! It expands it with .APP_ID. This also means that you do not need to customize your mime-type, as other answers propose. You can proceed with application/vnd.google-apps.drive-sdk, I suppose. I have checked: Google will even fix your mime type if some letters are misspelled, which makes the proposed customization even harder. Google API will take another mime type only if it is too different from REALTIME one. But I am not sure that this is a right thing to do, despite this is proposed by all other accepted answers as 'solution' because I do not know about the difference this implies. Nevertheless,
to to tie up, the reasons to use application/vnd.google-apps.drive-sdk instead of proposed custom types are:
This standard type is proposed by Google in realtime playground demos instead of custom type
Google calls this type 'REALTIME_MIMETYPE'. If your use something different, you use Realtime API to create non-realtime files. At least not that much realtime as proposed by google.
If you specify a different mime type, google still corrects it to REALTIME_MIMETYPE. This means that custom mime types are unwelcomed.
Proponents of customization do not understand anything of this. They even dare to laugh at Google official examples as 'ridiculous'. They basically say that we should not trust them.
Box:// seems to open the app, however I am not able to discern how to target a specific file.
Currently we don't have support for this, but it is a great idea that we'll consider for our roadmap.
We actually do support this. The best way to add this integration into your app is to use our OneCloud AppToApp framework (additional information available here http://developers.box.com/the-box-sdk-for-onecloud-on-ios/)
This is easy using the app-to-app framework. You just need to call BoxAppToAppAPI's sendFileDownloadRequestToApplication:withMetaData: if you want an app to go to a particular file and in Box's case download/preview it.
To make it go to the Box app you can simply pass in [BoxAppToAppApplication BoxApplication] in the first parameter.
As for the metadata parameter, you can create it with BoxAppToAppFileMetadata's appToAppFileMetadataWithFileName:fileExtension:folderPath:mimeType:fileID:folderPathByID:exportToken:username:
Assuming your app already integrates with the Box API via the SDK or otherwise, it should be able to get all of that information easily.
If the mimeType is not known, nil can be passed in. Also, nil can be passed in for the exportToken if the file was not exported out of the Box app (with the AppToApp framework, a roundtrip scenario is also supported where the user starts in the Box app, picks a file to view/edit/etc in your app, and then sends it back to Box to upload). So if it's not a round-trip, it's just a one-way from your app to Box, use nil for the exportToken.
Before doing this, you can also check if the Box app is installed by checking for [[BoxAppToAppApplication BoxApplication] isInstalled].
Below is a fictional example (the values are made up):
BoxAppToAppFileMetadata *metadata = [BoxAppToAppFileMetadata appToAppFileMetadataWithFileName:#"fileName"
fileExtension:#"png"
folderPath:#"All Files/Folder1"
mimeType:nil
fileID:[NSNumber numberWithLongLong:123456]
folderPathByID:#"0/12345"
exportToken:nil
username:#"username#email.com"]
BoxAppToAppStatus status = [BoxAppToAppAPI sendFileDownloadRequestToApplication:[BoxAppToAppApplication BoxApplication]
withMetaData:metadata];
I've successfully installed and run the Google Drive Quick Start application called DriveCommandLine. I've also adapted it a little to GET file info for one of the files in my Drive account.
What I would like to do now is save the credentials somehow and re-use them without the user having to visit a web page each time to get an authorization code. I have checked out this page with instructions to Retrieve and Use OAuth 2.0 credentials. In order to use the example class (MyClass), I have modified the line in DriveCommandLine where the Credential object is instantiated:
Credential credential = MyClass.getCredentials(code, "");
This results in the following exception being thrown:
java.lang.NullPointerException
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:187)
at com.google.api.client.json.jackson.JacksonFactory.createJsonParser(JacksonFactory.java:84)
at com.google.api.client.json.JsonFactory.fromInputStream(JsonFactory.java:247)
at com.google.api.client.googleapis.auth.oauth2.GoogleClientSecrets.load(GoogleClientSecrets.java:168)
at googledrive.MyClass.getFlow(MyClass.java:145)
at googledrive.MyClass.exchangeCode(MyClass.java:166)
at googledrive.MyClass.getCredentials(MyClass.java:239)
at googledrive.DriveCommandLine.<init>(DriveCommandLine.java:56)
at googledrive.DriveCommandLine.main(DriveCommandLine.java:115)
I've been looking at these APIs (Google Drive and OAuth) for 2 days now and have made very little progress. I'd really appreciate some help with the above error and the problem of getting persistent credentials in general.
This whole structure seems unnecessarily complicated to me. Anybody care to explain why I can't just create a simple Credential object by passing in my Google username and password?
Thanks,
Brian O Carroll, Dublin, Ireland
* Update *
Ok, I've just gotten around the above error and now I have a new one.
The way I got around the first problem was by modifying MyClass.getFlow(). Instead of creating a GoogleClientServices object from a json file, I have used a different version of GoogleAuthorizationCodeFlow.Builder that allows you to enter the client ID and client secret directly as Strings:
flow = new GoogleAuthorizationCodeFlow.Builder(httpTransport, jsonFactory, "<MY CLIENT ID>", "<MY CLIENT SECRET>", SCOPES).setAccessType("offline").setApprovalPrompt("force").build();
The problem I have now is that I get the following error when I try to use flow (GoogleAuthorizationCodeFlow object) to exchange the authorization code for the Credentials object:
An error occurred: com.google.api.client.auth.oauth2.TokenResponseException: 400 Bad Request
{
"error" : "invalid_scope"
}
googledrive.MyClass$CodeExchangeException
at googledrive.MyClass.exchangeCode(MyClass.java:185)
at googledrive.MyClass.getCredentials(MyClass.java:262)
at googledrive.DriveCommandLine.<init>(DriveCommandLine.java:56)
at googledrive.DriveCommandLine.main(DriveCommandLine.java:115)
Is there some other scope I should be using for this? I am currently using the array of scopes provided with MyClass:
private static final List<String> SCOPES = Arrays.asList(
"https://www.googleapis.com/auth/drive.file",
"https://www.googleapis.com/auth/userinfo.email",
"https://www.googleapis.com/auth/userinfo.profile");
Thanks!
I feel your pain. I'm two months in and still getting surprised.
Some of my learnings...
When you request user permissions, specify "offline=true". This will ("sometimes" sic) return a refreshtoken, which is as good as a password with restricted permissions. You can store this and reuse it at any time (until the user revokes it) to fetch an access token.
My feeling is that the Google SDKs are more of a hinderence than a help. One by one, I've stopped using them and now call the REST API directly.
On your last point, you can (just) use the Google clientlogin protocol to access the previous generation of APIs. However this is totally deprecated and will shortly be turned off. OAuth is designed to give fine grained control of authorisation which is intrinsically complex. So although I agree it's complicated, I don't think it's unnecessarily so. We live in a complicated world :-)
Your and mine experiences show that the development community is still in need of a consolidated document and recipes to get this stuff into our rear-view mirrors so we can focus on the task at hand.
Oath2Scopes is imported as follows:
import com.google.api.services.oauth2.Oauth2Scopes;
You need to have the jar file 'google-api-services-oauth2-v2-rev15-1.8.0-beta.jar' in your class path to access that package. It can be downloaded here.
No, I don't know how to get Credentials without having to visit the authorization URL at least once and copy the code. I've modified MyClass to store and retrieve credentials from a database (in my case, it's a simple table that contains userid, accesstoken and refreshtoken). This way I only have to get the authorization code once and once I get the access/refresh tokens, I can reuse them to make a GoogleCredential object. Here's how Imake the GoogleCredential object:
GoogleCredential credential = new GoogleCredential.Builder().setJsonFactory(jsonFactory)
.setTransport(httpTransport).setClientSecrets(clientid, clientsecret).build();
credential.setAccessToken(accessToken);
credential.setRefreshToken(refreshToken);
Just enter your clientid, clientsecret, accessToken and refreshToken above.
I don't really have a whole lot of time to separate and tidy up my entire code to post it up here but if you're still having problems, let me know and I'll see what I can do. Although, you are effectively asking a blind man for directions. My understanding of this whole system is very sketchy!
Cheers,
Brian
Ok, I've finally solved the second problem above and I'm finally getting a working GoogleCredential object with an access token and a refresh token.
I kept trying to solve the scopes problem by modifying the list of scopes in MyClass (the one that manages credentials). In the end I needed to adjust the scopes in my modified version of DriveCommandLine (the one that's originally used to get an authorization code). I added 2 scopes from Oauth2Scopes:
GoogleAuthorizationCodeFlow flow = new GoogleAuthorizationCodeFlow.Builder(
httpTransport, jsonFactory, CLIENT_ID, CLIENT_SECRET,
Arrays.asList(DriveScopes.DRIVE, Oauth2Scopes.USERINFO_EMAIL, Oauth2Scopes.USERINFO_PROFILE))
.setAccessType("offline").setApprovalPrompt("force").build();
Adding the scopes for user information allowed me to get the userid later in MyClass. I can now use the userid to store the credentials in a database for re-use (without having to get the user to go to a URL each time). I also set the access type to "offline" as suggested by pinoyyid.
I am developing an AIR application that is supposed to run on desktop and mobile platforms.
For most Facebook functionality, I use the official GraphAPI for Flash, version 1.8.1.
To use the app, the user must login to Facebook, this works easily by first calling FacebookMobile.init(), and if it reports that the user is not logged in, logging in like this:
var webView :StageWebView = new StageWebView();
webView.stage = stage;
webView.viewPort = new Rectangle(0, 0, stage.stageWidth, stage.stageHeight);
FacebookMobile.login(handleLoginResult, stage, new Array(), webView);
All of this works very well, but logging out does not work as expected. Calling
FacebookMobile.logout(handleLogout);
does log out the user from Facebook, it seems, and handleLogout is always passed a true as first parameter. After this logout, when FacebookMobile.init() is called, it also correctly reports the user as not logged in. So I call the login() method from above again.
Then, the WebView opens, but closes itself immediatly, automatically logging in the user that just logged out, without showing any kind of Facebook login screen. But I want to be able to log in another user, by having to type in email and passwort.
Probably I should mention that the logging out happens when the application starts. The user can't log out himself, the application does so when starting, so that the user should be forced to login each time. Yes, this has a reason ;)
I'm sure this is some kind of caching problem, but how can I solve it with Flash/AIR?
Bit late but better than nothing right? I have seen this issue before when I was experimenting with the OAUTH api...
Found the potential solution while looking for a separate issue but with regards to caching/cookies...
This post explains what you need to do:
http://cookbooks.adobe.com/post_Cannot_logout_from_Facebook_on_Android_devices-19254.html
Basically its not a very pretty solution, but what it does is you manually delete the folders where the caching is happening.
Hope this helps.
Implementing "reallyLogout" from this answer for a similar issue worked for me:
https://stackoverflow.com/a/8199505/952779
Clear internet explorer cache & cookies, .. and it will log you out from StageWebView facebook login
UPDATE: Change also the app id from the descriptor xml file