I'm running into trouble with test users and the Picker component in my web applicaton.
A subset of my test users are receiving a 400: The server cannot process the request because it is malformed when attempting to access the picker. Some of them experience a looping sign-in beforehand.
The picker is constructed in the following way inside of a useEffect in a React component:
// if there's a non-config related bug, I would imagine it must be related to getting the access token here.
const accessToken = gapi.auth2.getAuthInstance().currentUser.get().getAuthResponse().access_token;
const view = new picker.DocsView(picker.ViewId.DOCUMENTS);
view.setIncludeFolders(true);
const pickerDisplay = new picker.PickerBuilder()
.enableFeature(picker.Feature.MULTISELECT_ENABLED)
.setAppId(appId)
.addView(view)
.addView(new picker.DocsUploadView())
.setOAuthToken(accessToken)
.setDeveloperKey(apiKey)
.setCallback(pickerCallback)
.build();
setPicker(pickerDisplay); // sets picker state
Because I am not receiving the error message and the application has not been verified, I believe this likely has something to do with the IAM.
I believe I've been able to eliminate managed browsers settings,
cookie settings, and extensions as possible sources of error.
I've also added the users to the GCP project with the Browser role, though
they did not receive invites. What do I need to try next to resolve
this issue?
I cannot provide a minimum reproducible example because this only seems to be confined to a subset of my users' browsers.
I reached out to Google support, but unfortunately this is not covered.
I need to get this application into production relatively soon, so I'm very seriously considering just writing my own Drive microservice and recreating the Picker. I would love to avoid this though.
Related
I am trying to put a file to Firebase Storage with the following:
final metadata = firebase_storage.SettableMetadata(
customMetadata: {'firebaseStorageDownloadTokens': customToken});
_uploadTask =
_storage.ref().child(filePath).putFile(widget.file!, metadata);
I get the following error in my console:
E/StorageException( 6906): Caused by: java.io.IOException: { "error": { "code": 400, "message": "Not allowed to set custom metadata for firebaseStorageDownloadTokens" }}
Submitting this as both a bug & feature request on the plugin site, but in the meantime, in the off-chance I'm just writing this wrong, as documentation on this isn't thorough, I thought I'd submit here to see if anybody has done it successfully from the client.
I'll be writing a cloud function later if I can't do it from client, but since this isn't a high security thing I'm doing...I have many reasons to avoid forcing my app to get the downloadUrl....my aim is to create a predictable downloadUrl...readily done in the cloud, I know, just looking to do it from the client here.
After talking to some folks, this is not allowed from the client. It has to be done with a Cloud Function. It's highly discouraged. Here is why:
Anyone can access images if they have the image ID and the downloadToken. The idea is that both are hard to guess...hence an modicum of security. You can set security rules to getDownloadUrl for authenticated users, hence "restricting" the viewability through the obscurity of the image name, downloadToken and location.
By manually setting a downloadToken, you erode that "security."
It is allowed, however, you have to do it with a cloud function, triggering on create of the image, over-writing the auto-generated downloadToken. Send me a DM for help in that if you need it.
So, I wanted to create a new social media app using Swift and Parse. When I go to the Parse site, and click on dashboard, it gives me a login screen. I don't have an account, so I click on the "I don't have a parse account" button. When I click on that, it just takes me back to the home page. I did manage to get the code and frameworks and stuff that I needed from the docs, but that didn't quite work. It gave me this for the initialize code:
let configuration = ParseClientConfiguration {
$0.applicationId = "YOUR_APP_ID"
$0.server = "http://YOUR_PARSE_SERVER:1337/parse"
}
In the tutorial I'm watching, rather than "YOUR_APP_ID" and "http://YOUR_PARSE_SERVER:1337/parse" it just had a bunch of letters and numbers, which I would assume are the app ID and Parse server. My guess is, that I need an account to get those. Would that be correct? And, does anyone know why I can't seem to get an account? Thanks.
Parse.com is shutting down, so that's why you are not allowed to create new accounts on the service. Check the blog post.
They open sourced a nodeJS implementation, which you should definitely check out at link, and here is an example to get you started. You can easily use the deploy buttons to host the server on services like Heroku, AWS, Azure, etc. You can also deploy a server locally, for testing purposes.
Although it's true that Parse is discontinuing early next year, you can still setup a new app if you want to use the service for a shorter term project. Replace your code with the following.
Parse.setApplicationId("YOUR-APP-ID", clientKey: "YOUR-CLIENT-ID")
You can find your App ID and Client ID in your app's settings > security & keys.
EDIT: You definitely need an account for this to work.
I've been trying to get OAuth 2.0 to work correctly. I have managed to make the url that that will do the "deny/allow" for my app by opening a webpage with just
Application.OpenUrl(uri.ToString());
The problem is that I have no idea how to get the redirect and the auth token from the page if the user hits allow. When you hit allow, right now nothing happens it just sits on the page. Checking Networking in chrome debug does have the redirect and token there but it never actually sends it..
I was recommended to use RestSharp but I again have no idea how to use it with Unity as there are lot of resources for Android/iOS PC etc. but I can't get any of them to work for this Unity project...
var client = new RestClient("https://www.fitbit.com/oauth2/authorize?response_type=code&client_id=*clientID*&redirect_uri=http%3A%2F%2FfitRPGcallback&scope=activity%20profile%20sleep%20social");
Debug.Log("client made");
var request = new RestRequest(Method.POST);
request.Resource = ("profile%20sleep%20social");
client.ExecuteAsync(request, response => { Debug.Log("response is : " + response.Content);});
Application.OpenURL(client.BaseUrl.ToString());
In the URL I do have the correct clientID in there as well just not sure what I can and can't show for security reasons etc.
Biggest problem is just having no idea how to get the return value from the webpage after the user hits allow/deny...
Any insights would be super super appreciated cause I just want to start making the actual game but there's not as much point if I can't get this data...
So, I'm posting on a few other applicable questions as well since I have finally figured out my answer.
Unfortunately I'm not using REST so that part is still up in the air BUT I did get it to work with just Fitbit, Unity and a Webview plugin (you will need a webview OR a way to get the initial code back from your first OAuth2 call)
You can find steps here.
http://technicalartistry.blogspot.nl/2015/07/oauth2-unity-and-month-of-cursing.html
EDIT:
So I had to change how I did it because Fitbit changed their ToS where we are no longer allowed to use Webview based Authenticators (which is what I was using in the above blogpost.)
Give this next post a look for how to make an Android Plugin that will grab the Accesstoken from Fitbit's OAuth. This is a FREE way to do it since you make it yourself and it's ezmode :)
http://technicalartistry.blogspot.ca/2016/01/fitbit-unity-oauth-2-and-native.html
I was trying out the new enhanced revocable sessions in Parse on my Android app. It works well when logging in or signing up via email password or facebook but doesn't work well for custom authentication, e.g. google+.
I'm currently logging in the user using the cloud code which also creates the new user when signing up. This does not create a new Session object, that means the new enhanced sessions are not used and it still uses the legacy sessions.
I pass the session token back to client where using the become method the user logs in but it's the legacy sessions.
This feels like the feature is not complete but I would really like to move to the new enhanced sessions with my app. Has anyone worked with them yet? Are there any workarounds using the REST API or by creating the sessions manually and handling them manually? I looked into the JS API but it says it's only read only.
Here's the Blog post on Enhanced Sessions.
Where should I go next?
Yes, I found a solution but it's a workaround, works for my case because I don't support signing up with user/password.
Basically, the solution (cloud code) in semi pseudo-code is:
Fetch the user with master key
Check if user.getSessionToken() has value
if it has, return the session token and do a user.become() in the client as usual
if it's not, here the workaround, do the following:
yourPreviousPromiseInOrderToChainThem.then(function(user)
password = new Buffer(24);
_.times(24, function(i) {
password.set(i, _.random(0, 255));
});
password = password.toString('base64')
user.setPassword(password);
return user.save();
}).then(function(user) {
return Parse.User.logIn(user.get('username'), password)
}).then(function(user) {
var sessionToken = user.getSessionToken();
// Return the session token to the client as you've been doing with legacy sessions
})
That means, I'm changing the user password each time in order to make a remote login and, of course, I know thist can't be applied to all cases, it's enough for app because I don't support login with user/password (only third party logins) but I understand that maybe it's not for all cases.
I got the idea from this official Parse example.
I don't like this solution because I think is not a workaround, it's a mega hack but I think there is no other way to do it currently (either Parse.com or Parse-Server)
If you find other workaround, please, share it :)
I am working on a library in LUA for an ipad app called Codea. I'm trying to figure out to use OAuth for GitHub Gists. Only part that i can not figure out is how to get an Auth token via code. I used curl in terminal to get myself a token but this seems to be to much work for other users.
I've read through the github api docs multiple times but I cant figure out how to get a Token programmatically. I've tried to duplicate the method I've used to GET and POST gists but it does not seem to work. I'm not sure how to pass the username and password.
I'm creating a table with the needed params then encoding it in json. Everything I try gets a 404 error or 500 error. Thank you all in advance.
local url = "https://api.github.com/authorizations"
local d = {}
d.scopes = {"gist"}
d.note = "AutoGist Codea"
projectAuth = json.encode(d)
opts = { data = projectAuth }
opts.method = "POST"
opts.headers = {Authorization = "basic " .."username:password"}
http.request(url,successCallback,failedCallback,opts)
Scopes are coming, but only in Q4 2013.
See "OAuth changes coming" (October 2013, by Tim Cleam - tclem):
Starting today, we are returning granted scopes as part of the access_token response.
For example, if you are making a POST with the application/json mime-type you’ll see an additional field for the granted scopes.
{
"access_token":"e72e16c7e42f292c6912e7710c838347ae178b4a",
"scope":"repo,gist",
"token_type":"bearer"
}
Right now, these scopes will be identical to what you requested, but we are moving towards a feature set that will allow GitHub users to edit their scopes, effectively granting your application less access than you originally requested.
You should be aware of this possibility and adjust your application behavior accordingly.
Some things to watch out for and keep in mind:
Most third party applications using GitHub OAuth to identify users have the best success in adoption by starting out with a request for the minimum access that the application can possibly get away with.
Something like no scopes or just user:email is very sane.
It is important to handle the error cases where a users chooses to grant you less access than you originally requested.
Now that we are surfacing the granted scopes on the access_token response, applications can warn or otherwise communicate with their users that they will see reduced functionality or be unable to perform some actions.
Applications can always send users back through the flow again to get additional permission, but don’t forget that users can always say no.