Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
chbndrhnns
@chbndrhnns
Hey there, does someone know about efforts for making oauthlib available for FastAPI?
Jonathan Huot
@JonathanHuot
hi @chbndrhnns , fastapi seems very close to the bottle framework. So I guess the effort is similar to bottle-oauthlib (one simple file providing decorators)
agarwalvishakha18
@agarwalvishakha18
Hey. I have upgraded oauthlib to 3.1.0. I am using the library for my auth test cases. They are failing now and the error coming is http://paste.openstack.org/show/764384/
Can anybody help in there
Jonathan Huot
@JonathanHuot
Hi @agarwalvishakha18 , let me see
do you have the code called whhich hgenerate the exception please?
agarwalvishakha18
@agarwalvishakha18
Thanks for the reply @JonathanHuot . Here I have pasted the whole backtrace http://paste.openstack.org/show/764541/
Jonathan Huot
@JonathanHuot
Hi @agarwalvishakha18 , it seems flask is providing a class which is kind of hybrid between list & dict and provide this error because of this. I'm not seeing any recent changes in Keystone or in oauthlib, so I'm thinking it's a longstanding issue
a quick fix will be to provide a dict instead of the werkzeug.datastructures.EnvironHeaders type; e.g.
adds: headers=dict(flask.request.headers) in create_request_token_response
agarwalvishakha18
@agarwalvishakha18
Thanks @JonathanHuot for the quick help :)
agarwalvishakha18
@agarwalvishakha18
@JonathanHuot Got another error http://paste.openstack.org/show/764714/
Jonathan Huot
@JonathanHuot
yes, that's the same error than before. You need to add dict() around flask.request.headers
agarwalvishakha18
@agarwalvishakha18
Hi @JonathanHuot, it isn't having any impact over it. https://review.opendev.org/#/c/677511/ , the result is still same.
Jonathan Huot
@JonathanHuot
Hi, basically you have to pass a dict to this function. If you are passing another type, it's unlikely to work. Not much we can help here
agarwalvishakha18
@agarwalvishakha18
@JonathanHuot Thanks for the help.
Jonathan Huot
@JonathanHuot
@agarwalvishakha18 : you're welcome, don't hesitate to ask other questions if you have other errors with the oauthlib interfaces!
Anthony
@tribals
Hi there
I'm stuck with scope validation on authorization request.
Anthony
@tribals
According to spec, authorization server may partially or fully ignore the scopes passed by the client. That is, if I understand correctly, scopes requested by client is completely optional. Authorization Server must not respond with invalid_scope error if authorized user doesn't have scopes requested by client. Rather, resulting authorized scopes in this case simply should be reduced to user's scopes, is it? Is it correct that AS respond with invalid_scope error if and only if scope parameter is malformed, or client requested scope(s) that doesn't exist at all?
Anthony
@tribals
Here is the implementation of validate_scopes from GrantTypeBase:
File: oauthlib/oauth2/rfc6749/grant_types/base.py
77: class GrantTypeBase(object):
<...snip...>
166:     def validate_scopes(self, request):
167:         """
168:         :param request: OAuthlib request.
169:         :type request: oauthlib.common.Request
170:         """
171:         if not request.scopes:
172:             request.scopes = utils.scope_to_list(request.scope) or utils.scope_to_list(
173:                 self.request_validator.get_default_scopes(request.client_id, request))
174:         log.debug('Validating access to scopes %r for client %r (%r).',
175:                   request.scopes, request.client_id, request.client)
176:         if not self.request_validator.validate_scopes(request.client_id,
177:                                                       request.scopes, request.client, request):
178:             raise errors.InvalidScopeError(request=request)
In which case request_validator.validate_scopes should return False in order GrantTypeBase.validate_scopes to raise InvalidScopeError?
Benjamin Cordes
@benjyz
authlib links to https://github.com/lepture/flask-oauthlib which says "You should use https://github.com/lepture/authlib instead."
kind of confusing
Jonathan Huot
@JonathanHuot
Hi @benjyz, if you are looking for using oauthlib, you have multiple active projects which are bottle-oauthlib, django-oauth-toolkit, flask-dance. However flask-oauthlib is no longer maintained and the author rewrite the project w/o oauthlib framework and is now called authlib.
Hi @tribals , I think the doc could be improved
Jonathan Huot
@JonathanHuot
@tribals, as I read it from the RFC, it depends of the AS policy. If you does not allow a default scope, then return False in validate_scopes when request.scopes is empty (and let get_default_scopes returns nothing).
If your AS policy allows that, Then, if request.scopes is empty, return True :)
Anthony
@tribals
Is it correct that RequestValidator.validate_scopes does nothing with actually authorized scopes. I mean, scopes that will be returned in response?
Jonathan Huot
@JonathanHuot
you have to update request.scopes to the reduced list of authorized scopes, if any
& then return True / False as we said
Anthony
@tribals
Ok, got it. Thank you!
Jonathan Huot
@JonathanHuot
however improvement of the docstring of validate_scopes will be helpful if you want to do a PR that's welcomed :D :D
Tim Van den Eynde
@Timvde
The spec says: "The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters.", but it does not say the query parameters need to be interpreted
Ow, nvm, I misread it.
Tim Van den Eynde
@Timvde
It makes no sense though
Jonathan Huot
@JonathanHuot
Hi @Timvde, for /authorize parsing GET parameters makes sense, however for POST it doesn't. Are you looking for something in particular ?
Tim Van den Eynde
@Timvde
No, one of our users was doing a POST to get a token with his password in the GET parameters (which works), so we were looking into whether that was valid
It makes no sense, but if I read the spec correctly, it is still valid
Oh, unless... "The endpoint URI MUST NOT include a fragment component."
I'm still new at reading specs, so I'm not sure what that means exactly
Tim Van den Eynde
@Timvde
Oh, or is a fragment the part after a #? In that case, nvm
I think it's technically valid
Jonathan Huot
@JonathanHuot
@Timvde , if you want to continue to use query argument with POST you may want to pinpoint the version <3.1.0 . You will have details in the RFC which states it MUST NOT be in the query. See https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485000169 . Quote: "The parameters can only be transmitted in the request-body and
MUST NOT be included in the request URI."
Tim Van den Eynde
@Timvde
I actually don't want to allow it, I just thought I had to after reading the RFC...
But if it isn't actually part of the RFC and updating oauthlib solves it, I'll glady perform the upgrade and disallow it
Jonathan Huot
@JonathanHuot
that's great! you can read the part mentionned in the #666 ticket and let us know if you have any questions
Tim Van den Eynde
@Timvde
Thank you for your help :)