I'm working on supporting login by Github OAuth. But I encounter a problem:
When I log in to the Github once, the subsequence OAuth requests will fail with the 302 HTTP status.
When the OAuth request failed, the HTTP request is as follow:
The HTTP response is as follow:
I know the 302 response is caused by the "user_session" in the HTTP request.
My question is that is there any way to disable the user_sesion in the HTTP request. I want to send a totally new HTTP request for each OAuth request.
Thanks!
I tried the solution at Disabling cookies in WKWebView. But it doesn't work for me.
After using
myRequest.httpShouldHandleCookies = false
The WKWebView stops working. I guess it may be caused by the server cannot add cookies to our web browser.
The solution described at https://stackoverflow.com/a/31803708/10399490 works for me.
Just remove the cookies added by the Github.
I haven't verified whether the solution introduces any other side effects
Related
I have to test rest api using rest assured API. The API is spring secured(Spring security mechanism is integrated by dev team for authentication). I am able to login using rest assured api and found the JSESSIONID also.
After successful login it send http status 302 means redirection and Cookie is found in Response headers which is used for further request.
Also when I press F12, the same APIs are hit with different HTTP status code. Requested URL : http://example.com/portal/home/xyz.html. One having status code 302 and other having status code 200.
Please see the image below: Headers information after pressing F12:
I am not able to redirect to the URL with the following code :
given().redirects().follow(false);
Check the documentation about the redirect following under the following link:
https://github.com/rest-assured/rest-assured/wiki/ReleaseNotes15
When we are accessing Asana API we are using the Asana node client v0.15.0 together with an Tampermonkey script. The Api is responding with an 401 (Unauthorized).
This worked a couple a days ago. I have tried with new Personal Access Tokens but still get the same error.
While fiddling the request I tried to change the auth-header Bearer to be lower cased.
Authorization: Bearer my-personal-access-token ->
Authorization: bearer my-personal-access-token.
This seems to work fine, that indicates that something changed on Asana's side.
The node-asana js client lib does not let me modify the request before sending it to Asana API.
According to Asana API support it is on stackoverflow that I should ask about help on this matter.
EDIT
By some further investigation it seems that when we send in the cookie
auth_token=My auth token we do get the 401 error. But If removing the cookie and reissue the request in fiddler it works fine.
Another note is that now we do not get any custom_fields in the response from e.g https://app.asana.com/api/1.0/tasks/TaskId
I'm a Developer Advocate at Asana. You've caught something that is a known issue and we're working on a fix :) We're rolling out a new version of our API. It's intended to be backwards-compatible with the older implementation, but giving us multiple forms of authentication is one of those cases where we do something different between the two.
For security purposes, we initially implemented this in the new version to not allow requests with multiple forms of authentication, but it turns out that in-browser integrations were affected in precisely the way you're seeing: being logged into Asana, which causes your browser to send your authorization credentials for requests to asana.com automatically, and also authorizing "the right way" for our API with OAuth or a Personal Access Token will end up breaking. We're working on a fix that will allow this to work for the case when both the logged in (cookie) user and the API (access token) user are the same.
If this is an urgent issue and you want to force the old behavior to happen while we roll out the fix in our newer API implementation, you can set a header as described in that link --^ to force your requests on to the old API. Once we get the new API fully deployed and stable, though, we'll deprecate that header, so please be cautious in relying on it for a long-term solution.
Sorry that this has caused issues for you, and thanks for creating this question to let us know!
I have been trying with the simple REST Client as well as the REST Plugin for Mozilla. I am getting
"HTTP/1.1 401 Unauthorized" response with
"{"error":"unauthorized_client","error_description":"the client is not authorized"}" in the body.
I have been successful in getting the auth code, and the below is the POST request for access token, (Scope is r_fullprofile)
https://www.linkedin.com/uas/oauth2/accessToken?grant_type=authorization_code&code=AQTQeBxBzbU2aNWaQM6Ff3Z3bUd8Gyg10W9G2DdqXgWiP0q7-M55c5PLtppP7Ni3Y-6A9C8yDkj9K4VfJ7QkRUFjuV-3AknA5jAahpsFJv3wYfr8XD8&redirect_uri=https://www.google.com&client_id=75wl6j5zndvfkp&client_secret=secret
The redirect_uri=https://www.google.com is the one used for getting auth code as well.
Do we need to perform any URL encoding before making the POST request?
When I log into the linked in to my app, it has the below tokens,
OAuth User Token: c3ae4cee-1b23-xxx-9d2a-206f578dee4d
OAuth User Secret: 76bc48cc-c94f-xxx-bf9d-a663f7003383
I am not sure where it is used. we are using API & secret key to get auth code.
Thanks in Advance.
This is a 2-step process.
First, go to:
https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=YOUR-API-ID&scope=r_basicprofile&state=STATE&redirect_uri=YOUR-ENCODED-REDIRECT-URI
Then, within 10 secs of receiving the response, go to:
https://www.linkedin.com/uas/oauth2/accessToken?grant_type=authorization_code&redirect_uri=YOUR-ENCODED-REDIRECT-URI&client_id=YOUR-API-ID&client_secret=YOUR-API-ID&code=THE-CODE-OBTAINED-IN-FIRST-STEP
The response of the second request will have the actual access token you need to use.
When I followed the two steps I faced an issue where I got an error as
{"errorCode":0,"message":"Access to posting shares denied","requestId":"TYWULO2WPZ","status":403,"timestamp":1497353538016}
So I had to remove the &scope=r_basicprofile since it was preventing reading all the Default Application Permissions
I faced a similar problem and the problem was with the initial authorization code. You should mention the scope=rw_company_admin or whatever it is that you want to authorize to while doing the initial redirect URL call. Something like this -
https://www.linkedin.com/oauth/v2/authorization?response_type=code&client_id=your_client_id&redirect_uri=https%3A%2F%2Fwww.google.com/&state=12345&scope=rw_company_admin%20r_emailaddress%20w_share%20r_basicprofile
I'm trying to make a GET request to the Asana API from the browser. Because this is a cross-domain request, the client first sends an OPTIONS request. I'm running into the same issue that was described in this Stack Overflow question a year ago, ASANA API and Access-Control-* headers, where the Asana API doesn't respond with the Access-Control parameters.
I'm wondering whether the new release of the Asana Connect and OAuth2 addresses this problem and I'm simply doing something wrong or if this is still unsupported.
(I work at Asana.) Sorry, looks like this slipped through the cracks.
We currently do not allow Cross-Origin requests. However, we do support JSONP if you use Oauth2 and authenticate with a bearer token. This allows you to make secure requests from a JS client.
Just append opt_jsonp=CALLBACK as a parameter to the request, where CALLBACK is the name of the javascript function you would like to be called back with the response data.
I've successfully managed to get an OAuth access token and am able to make requests on behalf of the user. I did, however, run into an interesting scenario early on when I made an accidental typo.
My initial page was: http://www.example.com where I made my request for a request token.
My callback URL was: http://example.com where I made my request for an access token.
It seem to trip up my try(make request for access token)catch(display error message).
I kept getting error message about a bad token request.
Any ideas?
'www.example.com' and 'example.com' are two different domains - the error was probably due to the callback url not being within the 'realm' of the original request. This is a security measure to make sure you cannot hijack a request and have the callback go to an evil domain.