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 <[email protected]> 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 [email protected].
> To post to this group, send email to [email protected].
> 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
> <https://groups.google.com/d/msgid/django-users/a8aed0ee-21e3-4bdd-ada3-cecf332ae876%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> 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 [email protected].
To post to this group, send email to [email protected].
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.
