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!
Related
I've successfully implemented Discord's OAuth2 flow using the authorization code grant type into my application. The end user navigates to Discord's OAuth2 link for my bot, authorizes its access, and Discord redirects them back to my site with a code querystring. The bot then exchanges this code for an access token by querying Discord's API. Documentation on this process is available here for reference.
However, roughly every 50-100 requests to the exchange endpoint, I receive a 403 with the error invalid_grant and the description Invalid "code" in request. Frankly, I don't understand how the code just provided by Discord's system is instantly invalid. The same user can complete the process again and no error is returned the second time.
Out of desperation, I tried toggling on the option in the Developers Dashboard named Requires OAuth2 Code Grant seeing that it said "if your application requires multiple scopes," but it made no effect. I've also tried endless debugging, but the circumstances under each occurrence are apparently random. Oddly enough, I can't find anyone with the same issue online.
Below is the request I'm making in Node.js using the superagent library. It matches the documentation and works perfectly, other than the response randomly being the error described.
superagent.post('https://discordapp.com/api/v6/oauth2/token')
.type('x-www-form-urlencoded')
.set('Content-Type', 'application/x-www-form-urlencoded')
.send({
client_id: process.env.BOT_ID,
client_secret: process.env.BOT_SECRET,
grant_type: 'authorization_code',
code,
redirect_uri: process.env.OAUTH2_REDIRECT_URI,
scope: 'identify guilds.join',
});
I can confirm that all variables match their expected values. The value of redirect_uri matches that of redirect_uri in the original URL used. code is the value of the code querystring returned through the OAuth2 flow.
What (if anything) am I doing wrong that's causing the error?
Update 1:
Discord has directed me to the API GitHub repo, and I found the issue closed here. Commented and will update here if I receive any helpful info or resolve the issue completely (hopefully the case).
Ran into the same issue using nodejs. Leaving here notes for prosperity:
On Node, if there is no explicit app.head() handler, the .post() handler receives all head requests
Several Android phones, upon being redirected from discord, first send a head request to the endpoint
Meaning:
The user authenticates on discord, then through the redirect back, does a head request. This pulls discord with the code, BUT directly afterwards it also does a post request, which will fail (as you already used the code once), and possibly un-authenticates the user.
Solution for my specific issue was an explicit .head handler for all callback endpoints, which basically just returned the same headers (a redirect) as the post one did, but without calling discord.
Hope this helps.
did you use the OAuth2 link to invite your bot to your server - with the correct permissions? If so, in your main.js file did you define the token?
I.e. bot.login(“YOUR_TOKEN_HERE”)
I would recommend not toggling the ‘Requires OAuth2 Code Grant’ as it is a pain to do anything with in the beginning.
Please let me know of any progress :)
I have an interesting problem. We have set up the Thinktecture Authorization Server from the trusty Identity Server 2 and gotten it to work a few months back. It is configured as a relying party for an already existing corporate identity server, so when we use the Code Flow example, click the "Start authorization handshake" we bounce over to the identity server, supply our credentials and get bounced back to the callback of the code flow with an access code, click the Get Token, and are granted with this fine jwt token. All seems fine.
However,
When we try this either from, for instance, postman, or our app development team from their development devices (android and iphone), it starts fine but when we call the token endpoint with our newly minted access code we get an "Anonymous client" response.
Looking at the web example from the CodeFlow example I see it posts basic authentication including a base64 value of the secret wich is missing from postman and our app team. I see no reference to this in the CodeFlow example so I have no idea where this comes from. If I hard code the Authorization BASIC [including the Base64 secret I snatched from the previous example] it does not change anything.
We'be been stuck for several days on this so any help would be gratefully appreciated. Any Ideas?
After a lot of recearch and hair pulling it seems the Postman client we are using does not support Code Flow and therefore does not include the Authorisation header we are missing. After capturing the traffic from Postman with Fiddler we manually added the basic authorization header with the client name and secret and got everything working. So as of now, postman does not work.
I hope postman does add support for codeflow in the future.
Atli
I'm currently working on an app that needs to integrate Vimeo. I'm therefore adapting my working OAuth2 client to allow authorization to Vimeo it's new beta API.
However, there are some things that are unclear to me, and the documentation is a bit vague on the matter.
Should I get the client authorized before authentication?
The user authentication url is https://api.vimeo.com/oauth/authorize, should I send a GET or POST request to this URL with the required parameters?
Should I send a basic authorization header (Authorization : basic base64(client_id:client_secret) along with authentication or should it be unauthenticated authorization header (Authorization : Bearer unauthenticated_access_token)?
Should I handle the authentication dialog through a UIWebView or through Safari?
Furthermore, I seem to get the error: { "error": "An unknown error has occured. Please let us know!"} when handling authentication through Safari. Does anyone have a clue on what actually went wrong or provide a way to find out? (Seems Vimeo improved their error displaying overnight ;))
The actual error I get is that the redirect_uri and client_id are missing, but I'm reasonably sure they get provided in the request body when doing a POST, or in the parameters when doing a GET. Any pointers?
Client authorization is not necessary to generate User authentication. Client authorization is only necessary to make unauthenticated api requests.
You don't make a request to api.vimeo.com/oauth/authorize, you send your user there. You should create a link, and put it on a page for your user to click. They will make a GET request to that endpoint, but it should not happen through your server.
Since your client is making a request to /oauth/authorize, there is no way you can define the headers. You will need to provide an authorization header to /oauth/access_token, and this should be Authorization : basic base64(client_id:client_secret)
We did fix a bug last night in our oauth error reporting :D. Sorry for the temporary confusion.
Without more information I can't really answer your error message. I'll add some comments, and then update this answer with more information.
I am connecting to the QB API using a Go library that I found for OAuth 1.0a: https://github.com/kurrik/oauth1a. I actually had everything working, and I cannot think of anything that I changed, but now every request I make is returned with token_rejected. From what I have read elsewhere, this usually means that my access token has expired, but even if I start the whole 3-legged OAuth process from the beginning I will get the same response as soon as I am verified. I have triple-checked my consumer key and secret, I know they are correct. I can plug in the Access Token and Secret created using the API Explorer into my code and it works just fine, so I know the problem is something related to the Access Token that I am getting back from QB. Everything looks OK when I print out the tokens that I am using, they do match what QB sends me back via the querystring after the handshake process. I have been banging my head against the wall all day now, any help would be great.
Just adding the answer, it was an issue with the Oauth Library code and is now resolved.
-Jarred
I have a working OAuth process for authorizing with Google. My app can get data from the Google Sites API from areas that only the account used to authorize it has access, so I know that much is working. The trouble is creating new data via the API. I consistently get "Unknown authorization header" when trying to POST to the endpoint. The real frustration appears when I try to use the Google Oauth Playground. I put in the credentials I have, put in the same endpoint and same request body, and try it there -- and everything works perfectly.
I'm using Ruby 1.9.3 on the API side, and I've tried with both oauth-ruby and the Google-written signet client. Both do the same thing. I've verified and re-verified that the credentials are as I expect them to be (both just checking, and using the same ones in the Oauth Playground and seeing them work).
I have no idea why this is happening, because there's precious little information coming from Google's API about what's actually wrong with my request.
For the record, I'm using;
Ruby 1.9.3
oauth-ruby and signet for clients
OAuth 1.0
HMAC-SHA1 hashing
3-legged authorization
As it turns out, the problem was because I was failing to include the Content-Type header in the request. Yes, this didn't make any sense to me, either, considering the error message, but that's what it was.