I am currently using Postman to test my REST API. I've built it using Ruby-On-Rails, and using devise_token_auth to manage users sessions. After a successful log in, my API is rendering a client, an access-token, a token-type(BEARER) and an Uid. These elements are needed for every request that requires the user to be logged in and have to be sent on the header.
Let's say I am creating an article using a POST. The first POST succeeds and creates the article but when I try to create another article, I get :
{
"errors": [
"Authorized users only."
]
}
I suspect either Postman is behaving as a different client after each request, or my API is creating an access-token for the user after each request.
I finally managed to fix the issue:
According to devise_token_auth gem documentation, the access-token changes each time the client queries the API. Thus, I had to update the access-token, on my headers, whenever I wanted to send a request to my API.
To prevent the access-token from being changed after each request, add the following line to confing/initializers/devise_token_auth.rb:
config.change_headers_on_each_request = false
I added an answer to this linked question that applies to this question also. Using Tests and Pre-Requests scripts you can have Postman automatically save and update the token after each request.
This lets you use Postman without having to set config.change_headers_on_each_request = false inside your Rails app.
Related
I'm currently developing an Single Page Application (SPA) that is attempting to implement EPIC's Standalone Launch with Dynamic Registration. I am currently stuck on the step that requires the SPA to register itself at the https://fhir.epic.com/interconnect-fhir-oauth/oauth2/register endpoint with a JSON Web Key Set. Every time I do this, I get a response back:
{
"error": "invalid_client_metadata",
"error_description": null
}
The request I'm sending looks like the following:
POST https://fhir.epic.com/interconnect-fhir-oauth/oauth2/register
Content-type: application/json
Authorization: Bearer <redacted>
{
"software_id":"<sandbox-id>",
"jwks":{
"keys":[
{
"e":"AQAB",
"kty":"RSA",
"n":"tK2-...<redacted>...Q93sc",
"kid":"1"
}
]
}
}
I'm generating private/public key pairs using WebCrypto and I've verified that the JWKS of the public key I'm sending over is valid (I have tested signing and verifying jwt's using WebCrypto and validated them on jwt.io)
I've created a minimal reproduction repo on github that shows this issue. I've also deployed that repo so you can see the issue yourself.
To walk through the steps, I've been able to successfully do the following:
1: Request an Authorization Code
2: Exchange the Authorization Code for an Access Token
I am currently stuck on specifically using the Access Token and registering my SPA via the /oauth2/register endpoint. I know that the Access Token I'm receiving back is valid as I can access other protected FHIR endpoints using it. I've tried making the request both in a browser and in Postman, neither seem to work.
I am starting to wonder if anyone has ever been able to successfully register using the dynamic registration endpoint before? Searching google and stack overflow for this specific issue returns nothing.
Couple of things to try:
In web-crypto.ts, you have the hash in the config set like this: hash: "SHA-384". Per the docs, it seems it should be this instead: hash: { name: "SHA-384" }.
If that doesn't work, try bumping down the key length to 2048.
Also, this isn't causing your issue but fyi that your scope parameter in the /authorize call is invalid. Valid scopes are openid and fhirUser (can include both separated by a space).
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 a Rails 5 API only app and an Angular JS Frontend app and would like to integrate with Asana API. I'm using the ruby-asana, omniauth and omniauth-asana gems.
I start the request using Asana's JS library like so:
var client = Asana.Client.create({
clientId: 172706773623703,
clientSecret: '<client_secret>',
redirectUri: '<redirect_url>'
});
client.useOauth({
flowType: Asana.auth.PopFlow
});
And the above does redirect me to Asana where I can login. On the redirectUri I'm giving a backend route (Rails 5 API only) which should handle the remaining on the authentication (using the JS only I get only a temporary token that cannot be self renewed meaning the user will have to authenticate every time the token expires. This is if I understood the documentation correctly).
So, on the controller I've created to handle the route, I have the following (from an example on Asana's documentation):
require 'omniauth-asana'
use OmniAuth::Strategies::Asana, <secret>, <secret>
creds = request.env["omniauth.auth"]["credentials"].tap { |h| h.delete('expires') }
strategy = request.env["omniauth.strategy"]
access_token = OAuth2::AccessToken.from_hash(strategy.client, creds).refresh!
$client = Asana::Client.new do |c|
c.authentication :oauth2, access_token
end
Now, the above doesn't work because 1) there's no request.env as this is an API only app, so I've followed the instruction on Omniauth and have added the following to my config/application.rb:
config.session_store :cookie_store, key: '_interslice_session'
config.middleware.use ActionDispatch::Cookies # Required for all session management
config.middleware.use ActionDispatch::Session::CookieStore, config.session_options
Now, in the request.headers I have _interslice_session which has some numbers. How can I create a Asana client with the above?
Any ideas?
OK, I think I see what you're attempting to do here; I think the best way forward is to start with how OAuth's Authorization Code Grant happens in general, then move into specifics for OmniAuth.
You send the user to a URL that Asana owns; that is, your goal is to get the user to visit a particular url. For Asana, this is https://app.asana.com/-/oauth_authorize. (Note that we respond with an error if you don't sent a correct client_id param, but feel free to check that link if you want). Do not send the client_secret during this request - it is intended to never be involved in client-side code, as this is insecure.
If they agree to give access, Asana sends back a redirect request to the user's browser with a short-lived code. That then means that your server will be called from the user's browser with this code as a parameter, so has to handle a new incoming request from the browser to whatever you specified as your redirect URI. Also, this location must be accessible by all users of your integration wherever they are.
You send this code from your server as a POST request to https://app.asana.com/-/oauth_token with your client_secret to Asana for a refresh token. This is where your application actually asks for credentials; the token given in the previous phases simply acknowledges that for a short time, the user has given your app permission to ask for these credentials, and your client_secret assures Asana that, for this server-side request, your app really is yours (it's like your application's password).
We send back an access_token which represents (approximately) a client-user credential pair that is valid for an hour.
You use these credentials to access our API on behalf of this user. We also send back a refresh_token which is long-lived, and used to get new short-lived access_tokens after they expire in a very similar way.
OK, so how this works with OmniAuth if I grok it correctly is that it expects to handle almost all of it. I'll be working through our omniauth example in our ruby-asana client library here: https://github.com/Asana/ruby-asana/blob/master/examples/omniauth_integration.rb
You set up OmniAuth with your client id and client secret
use OmniAuth::Strategies::Asana, <client_id>, <client_secret>
A request comes in, and you don't have credentials for it.
get '/' do
if $client
...
else
'sign in to asana'
end
end
The user clicks the sign in link, which (code omitted) sends them to the sign_in endpoint. This endpoint issues a redirect to /auth/asana
The browser requests /auth/asana from our server. If you look at that example, it's not implemented in our code. That's because the /auth/:provider is magically handled by OmniAuth.
This is where all the magic happens. OmniAuth handles the entire login flow above: send browser to our oauth_authorize above, then receive the callback and sticks the relevant params in the environment such that it knows "we just got the short lived code". By the time these lines get hit:
creds = request.env["omniauth.auth"]["credentials"].tap { |h| h.delete('expires') }
strategy = request.env["omniauth.strategy"]
you are inside a callback that OmniAuth has intercepted, gotten the needed creds, and set the creds in the environment. You shouldn't have to handle the oauth callback and token exchange manually.
Now, with the code you provided, I notice a few things right off:
You are causing the popup cycle to happen client side. It may be (and I strongly suspect) that this won't work with OmniAuth - it expects to handle the whole OAuth flow.
Based on the code snippet you provided, you aren't serving this out of a request-response cycle in the controller, rather, it appears that this is in the controller body and not out of an instance method. It may be a typo, but this needs to be in a method that is called back to outside of Rails (that is, a route must point to this a controller method that Asana can use to handle the browser request).
You shouldn't have to look at request.headers, I think - I'm not sure what the issues might be with request.env, but I suspect they may be unrelated to the API-only nature of your app. Are you sure that this is because it's API-only? After adding in the middleware, did you double-check that you can't access request.env? My hunch would be that persistent data in request.env will still be there, only it would require on the middleware being added in to do this. The instructions on OmniAuth simply say that you need to have a session store for your API - which makes sense to me, because APIs don't necessarily need to store state across requests, OmniAuth is telling you to put a session store back in.
I know this is a lot of info, but hopefully it helps you get on the right track. Cheers!
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