Re: More robust way of handling login_required decorator?

AUTH_REQUIRED = True/False # default False for backward compatibility Normal behaviour unless assigned a pointer to Login CBV or FBV that returns user to the original URI upon successful login. I suspect this needs to be posted on the Developer forum. -Joe -- You received this message becau

Re: More robust way of handling login_required decorator?

Wouldn't it make sense to add in SETTINGS.py AUTH_REQUIRED = True/False # default False for backward compatibility Then use an @auth_not_required decorator on the few pages it isn't? Does DJANGO SECURE have such a setting? On Saturday, July 13, 2013 6:56:24 AM UTC-4, Some Developer wrote: >

Re: More robust way of handling login_required decorator?

On 13/07/13 14:50, Peith Vergil wrote: django-braces have a LoginRequiredMixin. Using it is a much cleaner solution to overriding the dispatch method. Thanks for the tip. I'll check it out. -- You received this message because you are subscribed to th

Re: More robust way of handling login_required decorator?

django-braces have a LoginRequiredMixin. Using it is a much cleaner solution to overriding the dispatch method. On Sat, Jul 13, 2013 at 6:56 PM, Some Developer wrote: > I make heavy use the login_required decorator and for the most part it is > extremel

More robust way of handling login_required decorator?

I make heavy use the login_required decorator and for the most part it is extremely easy to use when using FBVs but when using CBVs one either has to add a dispatch method to the class calling the super classes dispatch method or you need to put the login_required in the url configuration which