-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: upgrade oauthlib and django-oauth-toolkit to new versions. #32631
Conversation
f98bb6c
to
840cad7
Compare
ae87584
to
d4a574e
Compare
token = token_generator.create_token(request, refresh_token=True) | ||
token_generator.request_validator.save_token(token, request) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The create_token
method was also saving token in the database in the previous OAuth lib (oauthlib==3.0.1) version which we were using.
https://github.com/oauthlib/oauthlib/blob/v3.0.1/oauthlib/oauth2/rfc6749/tokens.py#L341.
But in the latest version save_token
has been deprecated.
https://github.com/oauthlib/oauthlib/blob/v3.2.2/oauthlib/oauth2/rfc6749/tokens.py#L303
Now we need to save tokens explicitly.
PR-653: PR in which save_token functionaly was removed from oauthlib
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I am guessing that the refresh token must be saved either way. Is that correct?
- I am guessing that we don't need to save JWT tokens, but I'm not certain. I don't think you should spend time working on this, but does the following comment make sense to add?:
# We may not need to save our JWT tokens, but we do need to save the opaque Bearer tokens.
# However, since BearerAuthentication is deprecated, we may want to explore removing this save
# call in the future once the DEPR has been completed.
# See https://github.com/openedx/edx-drf-extensions/issues/284
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(1)
It seems refresh_token
is independent of the change that we're talking about here.
As you can see refresh token implementation in both versions is similar.
v3.2.2 implementaiton | v3.0.1 implementation |
---|
Your thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(2)
Yeah, it makes sense that if we're moving towards JWT we can skip the save call.
But there are other things to consider:
-
Although this OEP (oep-42) states that
BearerAuthentication (edx-drf-extension)
is deprecated, but it's still there (link to BearerAuthentication
class) -
Also this PR is in
edx-platform
where we have another quite similarBearerAuthentication
class (link to class). This class and its subclasses are being widely used in the code base (link to usage)
So final thoughts are, as long as the BearerAuthentication
is there, we need the save call
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Thank you for the note on the edx-platform BearerAuthentication classes. That was a surprise to me. I have updated the DEPR with the additional information. The point of that DEPR is to remove all of BearerAuthentication, so I simply missed these implementation details.
- What do you think of the following updated comment proposal:
# This save_token call is required with BearerAuthentication. Once the DEPR for
# BearerAuthentication is complete and it has been fully removed, we may no
# longer need to save the token, since JWT tokens don't rely on the database.
# See DEPR https://github.com/openedx/edx-drf-extensions/issues/284
Additionally, or alternatively, once this lands we can add a comment in the DEPR ticket pointing to the save_token call, and note the same thing.
a1feddb
to
a6b3d3e
Compare
a6b3d3e
to
24042ef
Compare
[inform] Apologies. I know I was tagged on this, and have it on my backlog, but have yet to get to this. Maybe someone else from arch-bom will pick it up. I am out until 19th or 20th. Thanks for this work. |
ff078bc
to
f0abc03
Compare
f0abc03
to
b7ec85a
Compare
I still plan to review, but one high-level comment would be to create a new issue for "Migrating django-oauth-toolkit from 1.x.x to 2.x.x", and move all relevant warnings and discussions on that topic to that ticket. From this ticket, you could simply mentioned that migrating DOT from 1.x.x to 2.x.x has complications that were moved to . Also, please tag me on the new ticket, because I do have thoughts about it. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Minor comments.
token = token_generator.create_token(request, refresh_token=True) | ||
token_generator.request_validator.save_token(token, request) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- I am guessing that the refresh token must be saved either way. Is that correct?
- I am guessing that we don't need to save JWT tokens, but I'm not certain. I don't think you should spend time working on this, but does the following comment make sense to add?:
# We may not need to save our JWT tokens, but we do need to save the opaque Bearer tokens.
# However, since BearerAuthentication is deprecated, we may want to explore removing this save
# call in the future once the DEPR has been completed.
# See https://github.com/openedx/edx-drf-extensions/issues/284
requirements/constraints.txt
Outdated
django-oauth-toolkit<=1.3.2 | ||
# greater version has breaking changes and requires some migration steps. | ||
# In 2.x.x releases the client_secret is being saved as a hash instead of plain text. | ||
# https://django-oauth-toolkit.readthedocs.io/en/latest/changelog.html#id12 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As noted in another comment, can we create a ticket for the 2.x.x upgrade and link to it here? We can note that the 2.x.x has some complications that are detailed in the ticket.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, can you confirm whether you can see the secrets unencrypted in the Admin UI, or if you only see it at creation time, and after that it needs to be stored outside the app? Thank you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ticket has been created.
Comment having link | ticket link |
---|
As mentioned in the doc we can only obtain the secrets before hitting save
button.
Click here to see doc |
---|
@robrap : |
5b0aa19
to
e2bc311
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. I have some nits around potential updates to two comments, but I'll leave that up to you.
I would like to add a comment on the BearerAuthentication DEPR that points back to the save_token call once this merges.
requirements/constraints.txt
Outdated
# django-oauth-toolkit version >2.0.0 has breaking changes. | ||
# More details mentioned on this issue https://github.com/openedx/edx-platform/issues/32884 | ||
# Versions from 1.3.3 to 2.0.0 have some migrations related changes. | ||
# so we're upgrading minor versions one by one. | ||
django-oauth-toolkit==1.4.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Proposed update to:
a. Make it more clear that these are two different points (although related), and
b. Replace 1.X.X with the next version that has migrations that you wish to protect against. Note that we'll already be past 1.3.3 in this PR, so it is already irrelevant.
# django-oauth-toolkit version >2.0.0 has breaking changes. | |
# More details mentioned on this issue https://github.com/openedx/edx-platform/issues/32884 | |
# Versions from 1.3.3 to 2.0.0 have some migrations related changes. | |
# so we're upgrading minor versions one by one. | |
django-oauth-toolkit==1.4.1 | |
# 1. django-oauth-toolkit version >2.0.0 has breaking changes. More details | |
# mentioned on this issue https://github.com/openedx/edx-platform/issues/32884 | |
# 2. Versions from 1.X.X to 2.0.0 have some migrations related changes. | |
# so we're upgrading minor versions one by one. | |
django-oauth-toolkit<1.X.X |
ef0f9cd
to
9cf2da3
Compare
9cf2da3
to
5e8e75d
Compare
2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production. |
2U Release Notice: This PR has been deployed to the edX production environment. |
…edx#32631) * chore: bump django-oauth-toolkit and oauthlib --------- Co-authored-by: Muhammad Umar Khan <[email protected]>
🔗🔗🔗 Issue link
#32515
📝📝📝 Description
django-oauth-toolkit
andoauthlib
versions have been pinned for the last 3 years due to test failuresdjango-oauth-toolkit==1.7.1
andoauthlib==3.2.2
django-oauth-toolkit
from1.x.x
to2.x.x
is a little bit tricky as in2.x.x
theclient_secret
is being hashedhttps://django-oauth-toolkit.readthedocs.io/en/latest/changelog.html#id12:~:text=%231093%20(Breaking,before%20hitting%20Save
whereas in the previous releases, it was just a plain text. That's why we're just upgrading
django-oauth-toolkit
to the latest1.x
release for now.🔍🔍🔍 Tested on
2.x.x
, it will update all the existingclient secrets
as well.