I am trying to integrate my iPad app with Box. I am having an issue with the Box API where files in the account of one user are returned for some other user. Here are the steps to reproduce this issue:
Make the authorization calls and get the access token as mentioned in this guide. For login, I am opening the Box login page in Safari. I have the specified a custom url scheme for the redirect url, which opens up my app after the user logs in.
Once you get the access token, make a call to list the contents of the root folder. This succeeds.
Delete the app from the iPad and rebuild it.
Again go to the login process (as in step 1), but this time use a different Box account to login. You get a new access code and OAuth token this time.
If you make the call to list the files using the new token, you will get the response from the earlier account. Ideally it should return the files for the currently authorized user.
Does Box use just OAuth to return response or does it use cookies as well? Because after authentication and receiving the access token, I also see a cookie from Box (verified using [[NSHTTPCookieStorage sharedStorage] cookies]).
I have tried repeating the above process by deleting all Box cookies before starting the authentication flow. Also, I am not saving the OAuth token on disk and retrieving it. I am not saving/caching the response in any way.
One more thing that I have noticed is that there can be two Box users logged in at once in Safari. Also, if I make the authentication request, get the access token and again make the authentication request, it shows the login page again (instead of showing the allow/deny access page). Is this intentional?
I am using the Box v2 API and iOS 5/6
Upon further inspection, the problem seems to be with Box servers caching response. I did a quick test with curl using two different access tokens created from the iPad app. I made a call to fetch the user files for the root folder using both tokens. The results were correct, i.e. I got the correct files for each account.
When I did the same test on the iPad app, the files for one user were returned for the other user. If I maintained a considerable gap between the two logins, I got the correct files.
To permanently fix this, I am setting the Cache-Control header to no-cache for the request to fetch the user's files.
But it is strange that I have to do this. Box needs to check their cache validation logic IMHO.
Related
So I currently have all my requests set up in postman and to be able to make the request to my api I first need to go to the Authorization tab and click "Get Access Token" then a new window appears showing the log in screen from the Identity Server where I can enter the correct username and password to obtain the access token.
I am now wanting to use Postman to test my api however when the access token expires the tests of course fail.
What I want to know is the best way to approach setting up a script that could run the authorization before that request/tests are run.
I can see lots of examples if you only use ClientId and Secret however our Identity Server also requires the user to log in with username and password as that information is needed so that the Identity Info can be included in the returned token as the api called in the request uses this to determine which user to return data for.
Really hitting a brick wall here as I cannot see a way to automate the identity login.
How do others deal with running automated tests against an api protected with IdentityServer login?
You would have to mimic the set of requests and responses that would normally go through the browser. For example, you first make an authorization request. The server responds with a 302 to a login page. You can grab the location header and call the login page. Then you would post the username and password to the login form's action, etc.
You can have a look at this example: https://github.com/curityio/token-handler-node-express/blob/master/test/login.sh this is a set of curl commands which perform such login to an instance of the Curity Identity Server.
You should be able to script it as a series of requests in Postman.
I am trying to integrate the Google sign in sdk into my site.
I have already added the GSI button to my site and on clicking it, google sends the IDtoken containing the user info to my oauth endpoint.
Using this token, I can now create a new user account.
So far so good.But I am not sure what I am to do from here.
Should I put this IDtoken into a http_only and secure, cookie so that all authz server requests will contain the userid?
I am seeing lots of cookie and local storage based data has been been added to my sites jar. Am I supposed to use them in any way?
What do I need to do after the token expires after 1 hr? Do I need to have my users login yet again? I did not get any refresh token along with the idtoken. Do I even need to handle the refresh token or is the gsi sdk supposed to take care of all that for me?
Another part which is not clear is what do I get from using the Google sign in button/sdk vs the general Oauth-openid flow.
This is a summary of an issue I filed directly with expo (it ws closed but I have asked for it to be reopened):
This issue happens whether using AuthSession.startAsync,
AppAuth.authAsync or WebBrowser.openAuthSessionAsync on iOS in
local development and published release (expo managed). Haven't tried
on standalone build yet.
Steps to Reproduce
user presses 'sign in' button, (app calls one of the above methods to kick start authentication session with a Salesforce oauth provider)
user enters credentials successfully
app goes through oauth redirects and returns user to our app and we get our access token.
user presses 'sign out' button (app calls revoke endpoint for token, then calls server endpoint to delete any browser cookie sessions for given account reference)
app navigates to sign in screen
user presses 'sign in' again (app calls the same method from above to start the authentication session with Salesforce oauth provider again)
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Expected Behaviour
steps 1 - 5 are all as expected. Step six should be
app redirects to Salesforce oauth provider sign in page, in unauthenticated state (ie no cookie or session data that was previously stored is still valid)
user is required to re-enter their credentials
oauth flow takes over and redirects the user into the app if the credentials were correct.
Actual Behavior
as per initial steps where the user is not even asked to enter their credentials (step 6):
instead of opening the sign in page, the app redirects itself back with an access token as if the user had successfully entered their credentials, even though any cookies/session data the browser stores should be invalid and necessitate a sign in.
Reproducible Demo
The code is in a private repo so I can't share details of it, but it's a very standard oauth flow, and seeing it's happening in all three of the method calls from the top suggests to me that it may be due to something in the WebBrowser.openAuthSessionAsync implementation. I have seen on the apple developer docs that SFAuthenticationSession has been deprecated in favour of ASWebAuthenticationSession. My understanding is that this (SFAuthenticationSession) is the browser used by expo's WebBrowser and the wrappers mentioned above (AppAuth and AuthSession) for the oauth interactions. I also see that it mentions it's for a one-time login, which perhaps explains why it would hold onto any session data and jump to the conclusion of re-authenticating without directly seeking credentials from the user, but it seems unhelpful to store a cookie without validating it, which is what appears to be the end result.
Notes
Essentially this is making it impossible for a user to sign out of our app, because the system browser, that we don't have control over, is keeping track of their authentication despite the session value no longer being valid against the server.
I've seen other people looking to find ways to clear cookies from the system browser, which may be what this issue relates to, though it doesn't appear to be possible to access the auth session's browser cookies in any way. This comment on a GitHub issue is exactly what I'm experiencing and need to find a solution to.
I would like users to be able to sign out, and then when they sign back in again they should have to enter their credentials again. Does anyone have any thoughts as to how this might be possible?
On iOS, it's now possible to pass in the following config to WebBrowser.openAuthSessionAsync to essentially treat it as incognito and ensure it doesn't retain any cookies. The effect is that the user will have to re-authenticate each time (even if there session is still active). I'm not aware of a similar approach for Android, however.
Code
const browserOptions = {
preferEphemeralSession: true
}
result = await WebBrowser.openAuthSessionAsync(authUrl, redirect, browserOptions)
I've been reading lots of documentation about Google API access and OAuth flow using it but I don't seem to get it working in my mind, so I want to get some help first in order to have a clear idea about how it works then I can code it using the corresponding API.
What I want to achieve is feed a Java application running in a PC with specific Google user data, like localization through Google Latitude API. In order to get this, OAuth must be used, so I need getting the user consent, then access the user data from the application running in my computer, and I don't know how to manage this.
I've already registered my application with the Google APIs Console and enabled the Google Latitude module. I've also tried the Latitude console application here and it works properly (a browser tab opened asking for a Google user; I entered it and I got the location data), but I'm having problems when trying to adapt the program flow to my needs.
In my application, the 'remote' user is supposed to send a request (a custom JSON message) to the server asking for service enable/disable, like allowing the server to track his/her position through Latitude. Then, AFAIK, the server should send to the user a URL so the user can give the consent, but I don't know how to get this URL and how the server realizes about this consent and gets the token (automatically? Google tracks this authorization process?). Once my server gets the specific user token, then I should be ready to get service data for that user using the received token.
As I said before, I've tried according to different references, but as the documentation seems to be really scattered and much of it is already deprecated, I've been unable to get it working.
Judging from your description, the installed app OAuth2 flow seems to be the right one for you.
At some point, presumably when a user is installing your desktop app, you should fire up a browser - either embedded one in your app or the default browser - and sent them to this Google OAuth2 endpoint. In your request, fill out all the parameters as required by the doc: Latitude API scope, client_id, etc. Google, as an authorization server, will take care of user authentication, session selection, and user consent. If the user grants access to her data to your API, you will receive an authorization code either in the title of the browser window or at a localhost port.
Once you have the code, you can exchange it for an access token and a refresh token. The access token is what you need to call the API and access the user's data. It is short lived though - check the expired_in parameter in the response, I believe it is 3600 sec. - so you will need to periodically ping the token endpoint with your long lived refresh token and exchange it for an access token.
You can find a more thoroough description of this flow in the doc linked above.
Background
We are integrating third party email solution into our site. When a user goes to the Mail page it must be automatically authenticated at the Mail site.
For now, the Mail link points to our page which automatically submits a form with the user's login and password. After clicking submit the user is redirected to the Mail site with authentication cookie.
The problem with this approach is that we do not want the user to see his Mail password, because we generate it automatically for him and there are some sane reasons not to show it.
Question
Is there any way to receive mail authentication cookies without sending the login information to the client and performing form.submit operation from the client's browser? Is there a better way to do what I'm trying to do?
Edit
Of course "I am trying to do it programatically". Looks like that there are no sane solution except pass these login/password to the client. Looks like we must accept that user can see his mail password and somehow make sure he cannot use this information to change password to some other value we will not know.
Edit: I didn't read the post correctly, I thought he was trying to login to a remote mail application, not one hosted on his own server. Ignore this answer.
When you login to the remote third party mail website, they will create a cookie (since HTTP is stateless, it's the only way it knows the user is authenticated unless they store some kind of session ID in the url). When you send the user to that site, the site needs to know how to authenticate the user. Even if you logged in from your application and grabbed the cookie, you can set a cookie on the users browser for another website. The only way for this to work is if there is some kind of development API on the third parties website you can hook into, or they allow you to use session id's in the URL.
Possible solution but has a security risk
If they allow you to set a session_id in the URL (for instance, PHPSESSID in PHP) then you could grab the session ID and append it to the URL when sending it to the user. I don't really like this idea since if the user clicks on a link in an e-mail, the new page will be able to check the referrer and see their session ID in the URL. This can become a huge security risk.
Lookup topics related to your mail vendor and "Pass-through Authentication." You did not mention what vendor/software you are using for your web mail solution, so I can't help you very much there. Other than forwarding the user's information (in a post request) to the login handler.
Generate unique IDs before sending an email and put them as hidden instead of username/password into form. Make them disposable (usable only once or usable once before successful entering the site)