Re: tracking intent during password reset process

Curious, hen you say 'touch contrib.auth.views.py', you don't mean modifying the Django core, do you?

Assuming that you are using contrib.auth.views.password_reset (you may need to adjust this strategy for a custom view, etc.):

A quick custom view that simply sets a parameter when it calls the generic view and a tweak to the URLconf could solve this:

Only need a single URLconf line for something like 'password/reset/' that calls the custom view. All password resets will run through this URL regardless of 'authorization level', as you put it.

url(r'^password/reset/$', myviews.pass_reset_set_redirect, name='password_reset')

In your templates, for each area, such as /instructor/*, the link to the password reset would look something like <a href='{% url 'password_reset' %}?next=instructor'. This will create a link to a URL path like 'password/reset?next=instructor'. How you generate that link (either based on context vars or directly in the template) is up to you and your design.

Custom view:

def pass_reset_set_redirect(request):

    DEFAULT_LOCATION = 'public'

    locations = { 'public': 'public_home', 'instructor': 'instructor_home', 'staff': 'staff_home' } # *_home are the names of the URL's that will be used for the redirect and should be resolvable by reverse(), etc.

    # set a default in the event that the ?next=* parameter is something that is not a key in locations

    redirect_url = locations[DEFAULT_LOCATION]

    # DEFAULT_LOCATION gets used if ?next=blah is not given at all

    if request.GET.get('next', DEFAULT_LOCATION) in locations:

        redirect_url = locations[request.GET.get('next')]

    # call the generic view with post_reset_redirect set to our URL name with all the benefits of Django doing the hard part of handling the rest of the request

    # https://docs.djangoproject.com/en/dev/topics/auth/default/#django.contrib.auth.views.password_reset

    return contrib.auth.views.password_reset(request, post_reset_redirect=redirect_url)

I haven't tested this so YMMV, and it probably needs a couple of imports, etc., but I'm hoping you get the idea. This approach is somewhat extensible as the locations can be easily expanded to adapt to new 'authorization' levels if you decide you need them, or can be pulled from the database, etc.

Someone let me know if I'm way off here, haven't written a FBV for a few years.

On Fri, Sep 5, 2014 at 3:13 PM, Koed00 <koed00@gmail.com> wrote:

I've been adding #tags to my auth urls to redirect traffic after signups and resets. This keeps most of the routing intact, but gives you a hook to redirect on in a later stage.

However, I'm not using django-registration so I can't give you any examples.

On Friday, September 5, 2014 11:23:54 PM UTC+2, Lee Hinde wrote:

I have three primary levels of access in my project.

The public at /  

Instructors at /instructor/

Staff at /staff/

The issue is with the password reset process.

If someone comes to /instructor/ and then goes through the password reset process I want them to end up at /instructor/ when they're done. Currently I've got everyone going to 

/ because I'd rather confuse staff and instructors than the public.  

I'm not sure how to carry their original intended url / level through to the end of the reset process. I am loath to touch contrib.auth.views.py for fear of introducing some obscure, or not so obscure, bug.  Users can be authorized to all three levels so monitoring their user level doesn't work.

I'm using django registration, hence registration/auth_urls.py and it occurred to me to just duplicate (or triplicate) the pertinent urls so that password/reset/complete/ becomes instructor/password/reset/complete/ and I could pass the appropriate next url to extra_context. But that doesn't seem very DRY so I thought I'd check in here to see if there was a better way.

Thanks.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a8aed0ee-21e3-4bdd-ada3-cecf332ae876%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciWsf-iv7--Jx2y3vHzx2S9buS88M5%2Bt1w4CgRypixF3dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.