You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem exists where: if someone uses the decoded_authorization_token values coming from the one Authorization header instead of relying on the other 4 headers, the order of reading values is interrupted by reading from the params.
As a result, if either a path, query or body param contains an attribute with a name clashing with the defined client_name, uid_name or access_token_name, this will get evaluated before we can even try to evaluate the decoded_authorization_token (and this would be the same with the cookie).
As a result, auth fails for these requests.
GET /api/protected/some_resource?client=123
Authorization: Bearer a3dxd.....
===> Fails because client = 123 instead of the value in the Bearer token.
Could we issue a fix where we read from params after any other option has been tried ?
Hi,
There seems to be a bug in how we read the authentication attributes in concerns/set_user_by_token.rb.
On line 52 and after this is how it reads:
The problem exists where: if someone uses the
decoded_authorization_token
values coming from the oneAuthorization
header instead of relying on the other 4 headers, the order of reading values is interrupted by reading from theparams
.As a result, if either a path, query or body param contains an attribute with a name clashing with the defined
client_name
,uid_name
oraccess_token_name
, this will get evaluated before we can even try to evaluate thedecoded_authorization_token
(and this would be the same with the cookie).As a result, auth fails for these requests.
Could we issue a fix where we read from
params
after any other option has been tried ?The text was updated successfully, but these errors were encountered: