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

Login with "next" view that requires OTP and user that requires setup loses the "next" parameter #621

Open
cjsoftuk opened this issue Apr 27, 2023 · 0 comments

Comments

@cjsoftuk
Copy link

cjsoftuk commented Apr 27, 2023

Expected Behavior

When you have a target view from the login process passed in via "next" that's protected with the OTPRequiredMixin and the user is not set up with OTP, two_factor should redirects the user to the OTP setup view, preserving the "next" URL.

Current Behavior

The OTP Login Views send the "next" url to the session (https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L188), but it is then never reloaded from the session in https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L461

Possible Solution

Change https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L188 to hand the "next" URL off to the setup view, rather than saving it in the session. For example at https://github.com/jazzband/django-two-factor-auth/blob/master/two_factor/views/core.py#L189

            return redirect(
                '{view_url}?{query_string}'.format(
                    view_url=reverse('two_factor:setup'),
                    query_string=urllib.parse.urlencode({'next': self.get_success_url()})
                ))

This is possibly not going to cope with all edge cases, however, does cope with the specific use case I have.

Alternatively, it would be possible to change the Setup view to read from the session, however, I feel that the Login view should tell Setup where to go after setup, not Setup "finding out" via some stateful method using the session.

Steps to Reproduce (for bugs)

  1. Set up a view using OTPRequiredMixin (e.g. oauth2_provider's AuthorizationView for authorizing an app with a Bearer token)
  2. Attempt to log in to this workflow (e.g. as an OAuth2 login flow from oauth2_provider) with a non-2FA enabled account
  3. Watch as you get bounced to the setup
  4. Complete setup, and watch as you are not returned to the original oauth2 authorize page, but instead to "two_factor:profile" (by default).

Context

Your Environment

  • Browser and version: Chrome Version 109.0.5414.74 (Official Build) (64-bit)
  • Python version: 3.9
  • Django version: 3.2.16
  • django-otp version: 1.1.6
  • django-two-factor-auth version: 1.15.1
  • Link to your project: Not available - Commercial application
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

No branches or pull requests

1 participant