Skip to content
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

Merged
merged 3 commits into from
Aug 18, 2023

Conversation

awais786
Copy link
Contributor

@awais786 awais786 commented Jul 3, 2023

🔗🔗🔗 Issue link

#32515

📝📝📝 Description

  • django-oauth-toolkit and oauthlib versions have been pinned for the last 3 years due to test failures
  • In this PR we're unpinning them to django-oauth-toolkit==1.7.1 and oauthlib==3.2.2
  • Moving oauthlib to latest version wasn't a big deal as we only had to update a few method names
  • But moving django-oauth-toolkit from 1.x.x to 2.x.x is a little bit tricky as in 2.x.x the client_secret is being hashed
    https://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 latest 1.x release for now.

🔍🔍🔍 Tested on

  • Sandbox configured with ecommerce.

⚠️⚠️⚠️ Migrating from django-oauth-toolkit from 1.x.x to 2.x.x

  • We need to be aware that in the future if we do any attempt to migrate DOT to 2.x.x, it will update all the existing client secrets as well.
  • And then we can't downgrade its version. It's only one way.
raise IrreversibleError("Operation %s in %s is not reversible" % (operation, self))
django.db.migrations.exceptions.IrreversibleError: Operation <RunPython <function forwards_func at 0x7f6956652430>> in oauth2_provider.0006_alter_application_client_secret is not reversible

@mumarkhan999 mumarkhan999 force-pushed the upgrade-auth-lib branch 2 times, most recently from f98bb6c to 840cad7 Compare July 4, 2023 14:45
@mumarkhan999 mumarkhan999 self-assigned this Jul 4, 2023
@mumarkhan999 mumarkhan999 force-pushed the upgrade-auth-lib branch 5 times, most recently from ae87584 to d4a574e Compare July 7, 2023 12:14
Comment on lines 36 to 41
token = token_generator.create_token(request, refresh_token=True)
token_generator.request_validator.save_token(token, request)
Copy link
Member

@mumarkhan999 mumarkhan999 Jul 7, 2023

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I am guessing that the refresh token must be saved either way. Is that correct?
  2. 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

Copy link
Member

@mumarkhan999 mumarkhan999 Aug 17, 2023

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?

Copy link
Member

@mumarkhan999 mumarkhan999 Aug 17, 2023

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:

So final thoughts are, as long as the BearerAuthentication is there, we need the save call.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 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.
  2. 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.

@mumarkhan999 mumarkhan999 requested a review from robrap July 11, 2023 15:24
@mumarkhan999 mumarkhan999 marked this pull request as ready for review July 11, 2023 15:25
@robrap
Copy link
Contributor

robrap commented Jul 14, 2023

[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.

@robrap
Copy link
Contributor

robrap commented Jul 19, 2023

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.

Copy link
Contributor

@robrap robrap left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Minor comments.

Comment on lines 36 to 41
token = token_generator.create_token(request, refresh_token=True)
token_generator.request_validator.save_token(token, request)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I am guessing that the refresh token must be saved either way. Is that correct?
  2. 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

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
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member

@mumarkhan999 mumarkhan999 Aug 17, 2023

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

@mumarkhan999
Copy link
Member

mumarkhan999 commented Jul 27, 2023

@robrap :
[Inform] Apologies for the late reply. Actually, I was busy with the pymemcache related task. Will get back to you with the answers you asked on this PR. Thanks.

@robrap robrap added the waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. label Aug 3, 2023
@mumarkhan999 mumarkhan999 force-pushed the upgrade-auth-lib branch 3 times, most recently from 5b0aa19 to e2bc311 Compare August 17, 2023 08:54
@mumarkhan999 mumarkhan999 removed the waiting on author PR author needs to resolve review requests, answer questions, fix tests, etc. label Aug 17, 2023
Copy link
Contributor

@robrap robrap left a 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.

Comment on lines 33 to 37
# 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
Copy link
Contributor

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.

Suggested change
# 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

@mumarkhan999 mumarkhan999 merged commit 64abfd1 into master Aug 18, 2023
@mumarkhan999 mumarkhan999 deleted the upgrade-auth-lib branch August 18, 2023 09:21
@edx-pipeline-bot
Copy link
Contributor

2U Release Notice: This PR has been deployed to the edX staging environment in preparation for a release to production.

@edx-pipeline-bot
Copy link
Contributor

2U Release Notice: This PR has been deployed to the edX production environment.

@awais786
Copy link
Contributor Author

#33065

mehedikhan72 pushed a commit to mehedikhan72/edx-platform that referenced this pull request Aug 24, 2023
…edx#32631)

* chore: bump django-oauth-toolkit and oauthlib
---------

Co-authored-by: Muhammad Umar Khan <[email protected]>
@mumarkhan999 mumarkhan999 deleted the upgrade-auth-lib branch September 4, 2023 07:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants