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 <loai1...@gmail.com>
> 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 django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
