Thanks for user.is_authenticated(), , but Django built in login view
function doesn't call it before executing. So I guess I have to wrap Django
login myself when using it.
So the code will change to be this, I use this to wrap only Django login
function-since I cannot modify it-, otherwise I can
use user.is_authenticated().
def check_not_login(view):
def new_view(request,*args,**kwargs):
#the user is already logged in, redirect to the home page
if request.user.is_authenticated():
return HttpResponseRedirect('/faculty/')
return view(request,*args,**kwargs)
return new_view
On Wednesday, November 21, 2012 2:51:49 PM UTC+2, Daniel Roseman wrote:
>
> On Wednesday, 21 November 2012 12:04:45 UTC, Loai Ghoraba wrote:
>
>> Well, thanks very much for your effort-y reply. I have read it and it is
>> useful, though it requires a second reading to recap :)
>>
>> Well, I thought of a simple solution and it worked: just having a
>> wrapping function around django login such that it checks whether the use
>> is logged in or not before viewing the login page. I had to import the
>> SESSION_KEY variable used by django to set the user session. I think this
>> is a bad thing since they may change the variable name in future releases,
>> however they don't provide a getter method for it.
>>
>> cod: /* myview.py */
>> from django.contrib.auth import SESSION_KEY
>>
>>
>> def check_not_login(view):
>> def new_view(request,*args,**kwargs):
>> #the user is already logged in, redirect to the home page
>> if SESSION_KEY in request.session:
>> if request.session[SESSION_KEY]==request.user.id:
>> return HttpResponseRedirect('/faculty/')
>> return view(request,*args,**kwargs)
>> return new_view
>>
>> /*urls.py*/..
>> url(r'^accounts/login/$', check_not_login(login))
>> ..
>> and it is working :)
>>
>> On Wednesday, November 21, 2012 12:54:43 AM UTC+2, Issam Outassourt wrote:
>>>
>>> Hi,
>>>
>>> Well what you could do actually, and it's of commun use is to give your
>>> user a session-cookie id, which you can generate based on some informations
>>> in the header, typically his login, his ip adress, his password, his
>>> user-agent...
>>> As he tries to get the login page, challenge him by checking if the
>>> cookie is set.
>>> If it is set, you should recompute the value and check wether it
>>> matches. If it does, then you can redirect the response to another url,
>>> otherwise you show back the login page.
>>>
>>> Well, i'll give you the structure of the code :
>>>
>>> *login page*
>>>
>>> if(cookie_session_id is set):
>>>
>>> calculate new_cookie_session_id(remarkable data_headers,
>>> database information,...) //through concatenation and hashes
>>> if (new_cookie_session_id == cookie_session_id):
>>> return redirection_to_main_page
>>> else:
>>> return
>>> what_should_be_the_template_that_allows_the_user_to_identify_him_self
>>> else:
>>> return
>>> what_should_be_the_template_that_allows_the_user_to_identify_him_self
>>>
>>>
>>> *submit_page*
>>> /* after the user gets to give his own parameters and submit the form
>>> you should manage the data with a view function that sets the
>>> cookie_session_id for the session */
>>>
>>>
>>> if(the_user_has_the_right_to_authenticate_with_submitted_values):
>>> calculate cookie_session_id(remarkable data_headers, database
>>> information,...)
>>> set cookie_session_id
>>> return the_user_main_page
>>> else:
>>> return an_error_and_allow_your_user_to_log_again // or
>>> something of that kind
>>>
>>> DONE !
>>> The idea behind that is that if the facility is not offered or you did
>>> not afford the time to check the documentation, you can try to solve your
>>> problem by your own. Yet more, you should consider checking the
>>> cookie_session_id any time the user tries to browse a page that contains
>>> sensitive or not public information. What would help you do so is to add a
>>> widget in all pages that shows the login_form if not logged or
>>> login+photo+profile_link (be creative and make sure you check what happens
>>> security wise) information (template power, if you know what i mean ;))
>>>
>>> One thing to add is that to compute the value you're looking for, what
>>> is advised generally is to get important information that you believe
>>> identify well, or uniquely your user, concatenante all the stuff and hash
>>> it with very common hash algorithms such as md5, sha1...
>>> More to it, if you want to make sure that you don't have to calculate
>>> the cookie_session_id each time, all you need is to create a Class that
>>> inherits from models.User, add a ForeignKeyField that holds a list of
>>> couples coming from another table that you create and that can hold the
>>> cookie_session_id of your users and the last_request_date
>>>
>>> Class SessionId(models.Model):
>>> session_hash = models.TextField(whatever options you want)
>>> last_request_date = models.DateTimeField(feel free to
>>> customize)
>>>
>>> The purpose of this is to make sure that you update SessionId entries
>>> each time you receive a request, to make sure that outdated connections can
>>> be deleted and to allow your users to connect through different platforms
>>> at the same time, as the value of the cookie_session_id could depend as
>>> well on something unique to each machine (their ip adress for example, and
>>> their user-agent)
>>>
>>> So, your structure will change from that thing above to the following :
>>>
>>> *login page*
>>>
>>> if(cookie_session_id is set):
>>>
>>> calculate new_cookie_session_id(remarkable data_headers,
>>> database information,...) //through concatenation and hashes
>>> if (new_cookie_session_id == cookie_session_id,
>>> *and the session is not expired*):
>>> return redirection_to_main_page
>>> else:
>>> *make sure that the user is not authenticated and
>>> clear the foreign key entry if needed (that is to say if it exists and the
>>> session is outdated)*
>>> return
>>> what_should_be_the_template_that_allows_the_user_to_identify_him_self
>>> else:
>>> return
>>> what_should_be_the_template_that_allows_the_user_to_identify_him_self
>>>
>>>
>>> *submit_page*
>>> /* after the user gets to give his own parameters and submit the form
>>> you should manage the data with a view function that sets the
>>> cookie_session_id for the session */
>>>
>>>
>>> if(the_user_has_the_right_to_authenticate_with_submitted_values):
>>> calculate cookie_session_id(remarkable data_headers, database
>>> information,...)
>>> set cookie_session_id
>>> *add according entry in the foreignkey field, adding it as
>>> well in the sessionid table*
>>> return the_user_main_page
>>> else:
>>> return an_error_and_allow_your_user_to_log_again // or
>>> something of that kind
>>>
>>>
>>> I hope I gave you sufficient hints.
>>> Feel free to ask for more explanations if needed. I would be happy to
>>> help
>>>
>>> Regards,
>>>
>>>
>>> 2012/11/20 Loai Ghoraba <[email protected]>
>>>
>>>> Hi all
>>>>
>>>> I am trying to build a login page using Django auth app, it is all
>>>> working nice but there is one problem: If I browse to accounts/login (the
>>>> login url) when I am already logged in, in normal situation the login view
>>>> shouldn't be rendered and the correct action will be to redirect to the
>>>> home page/the request url/etc..
>>>>
>>>> But this just doesn't happen ! It renders the login view normally as if
>>>> I am not logged in!
>>>> I even checked the source code, and indeed it doesn't check whether the
>>>> user is already logged in.
>>>>
>>>> So is this a bug or something ?
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django users" group.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msg/django-users/-/YtY426bWAiUJ.
>>>> To post to this group, send email to [email protected].
>>>> To unsubscribe from this group, send email to
>>>> [email protected].
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/django-users?hl=en.
>>>>
>>>
>>>
> There's no need for any of this. Django provides a way to tell if a user
> is logged in: `request.user.is_authenticated()`. And there is already a
> decorator which wraps views: `@login_required`. All of this is documented:
>
> https://docs.djangoproject.com/en/1.4/topics/auth/#the-login-required-decorator
> --
> DR.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/XRDXlWwFioAJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
