Click to See Complete Forum and Search --> : log in and log out button, how do you handle it?


blackhorse
09-13-2007, 05:16 PM
for an online shop. You will have a log in button. People can browse around and not have to log in. But when they order etc. they will have to log in. After log in, then the "log in" button will be switch to a "log out" button.

My question is that, if the client uses the back button to the previous pages before he logged in. the button would still be "log in" button. Then if he wants log out, he cannot see the "log out" button.

Many web sites use this approach. I just don't think it is good practice. What do you think?

There are two approaches I used.

1) I always have the "log in", "log out" and "my account" buttons show there no matter you have logged in or not. But my clients always ask why other sites switch between "log in" and "log out" buttons, and I cannot do it for them. I told them that I can, I just don't want their web site users have to look for "log out" if they back steps to the pages before they log in.

2) or force every page to reload even if the user of the web site back button to the previous pages. This could be waste of the web resource, slow down the page just to satisfy the small request that either show "log in" or show "log out" but not both. I usually don't do it unless the client insisted.

So what is your choice?

rowanparker
09-14-2007, 03:40 AM
Erm.. I've only just thought of this.

But you could have the button in a very small iframe (with login button) so that when they go to a new page the new iframe is loaded (with logout button in) then when they go back the same iframe will be there with the log out button in.

Or you could do the same but just use an image instead of an iframe (loginout.php that loads either a login image or logout image) and just have src="loginout.php" then it will show either login or logout depending on whether the user is logged in or not. But there is a slight problem with this, you cannot change where the link will go to without refreshing. But you can just redirect to one page then will: if logged in then log out, if not logged in then send to login page.

Hope that gives you some ideas.

etully
09-14-2007, 05:00 PM
Your second approach shouldn't work because if the page comes from cache, the server won't be involved to display the right graphic (first approach probably won't work either). You could try to force the page to reload every time with a nocache statement but that's imperfect across browsers.

I suspect that having a little Ajax script check login status would be safer since the script runs when the page is displayed, not loaded.

I suppose if every single link on your site was a POST (instead of a hyperlink), then the back button would always force a refresh but that isn't very clean.

blackhorse
09-14-2007, 08:06 PM
etully, so you may do just like i did, keep both login, logout button there? i think it is perfect fine. just some of my clients maybe saw the login and logout switch in many other sites, and didn't understand that there was a back button to pre - log in pages issues in these sites and wondering why i cannot do it for them.

In my opinion, have an extra button (both log in and log out show) there better than when reader back button to pre-login page they cannot find the log out button.

etully
09-14-2007, 09:38 PM
etully, so you may do just like i did, keep both login, logout button there?
No, showing two buttons says to me that the programmer doesn't know what they're doing. Also, personally, as a customer, I look for that button to tell me whether I am actually logged in or out right now. In the past, what I've done is display either a login button or a logout button because none of my clients have ever complained about what happens when you log out and then press the back button. I'm saying that if I did have a client complain that the wrong button was showing (because the page came from cache), then what I would do is use Ajax to display the right button. If you press the back button, the Ajax script would run from scratch, contact the server, find out if this sessionid was logged in, and display the correct login/logout button. But like I said, I've never had anyone complain about the back button bringing them to a page with the wrong button. Besides, if the user presses the back button, it doesn't change the fact that they really are logged out so you could just make it so that both buttons bring you to the same place.

Alternatively (if you don't like Ajax), you could have a Javascript that checks a cookie and updates the button without contacting the server. That cookie would keep track of whether or not you're logged in... but only for the purposes of knowing how to display the button (because you would never trust a user cookie to determine login status). I actually like this solution best because there's less server overhead... but again, I've never had a customer complain about the wrong button showing in this situation.

schwim
09-14-2007, 11:06 PM
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="no-cache">
<meta http-equiv="Expires" content="-1">
<meta http-equiv="Cache-Control" content="no-cache">


Are various methods used to tell the browser not to cache the page(or put an expiration date older than the current date).

Stating that using the back browser would ignore the code has been disproved in my personal tests with the code. The fact that the code is at the top of the page has caused my browser to reload the page.

Does this not happen when you run this code etully?

thanks,
json

blackhorse
09-14-2007, 11:27 PM
OK, etully, I like the javascript checking out approach. And I will make the log in and log out goes to a same script and that script will detect what action the reader really want and then do as what they really want login or logout. These two approaches should be good enough.

as no-cache set up, I set up most dynamic pages as no-cache. But some dynamic pages of the site, I may want it with cache on. Such as when you register a new account, and submit, and then database finds out either the userid you select is already used and bounced you back to select the new userid. For these pages, I allow the cache, so they don't have to refill out all the information (of course, if the form has sensitive information, i will enforce the no cache). But if I allow the cache on these pages, use no-cache to force the reload will not work on these pages.

Plus, there are also a lot of pages with static contents only. These pages we usually allow cache, but if we want to switch the buttons, then even these pages I have to make them dynamic pages, every page is a php page then.

I usually use no-cache just to be on the safe side, and my site are not heavy traffic sites. Well, I may have to explore cache or no-cache in another thread to see which is better practice.

bradgrafelman
09-16-2007, 01:19 PM
You could always have the image source point to a PHP script which outputs the appropriate image as well as a no-cache header just for the image.

dougal85
09-19-2007, 08:16 PM
I've never thought about this before and never had a problem with a website. Come to think of it, I don't think I've ever logged into a website then thought, page back then log-out. How many people would actually do that?

I've always just done the switching. I personally don't like showing links that are not relevant to the users current state.

halojoy
09-25-2007, 08:33 PM
hi.
Another issue is the following case:

Say a person is on a protected page, only for logged in users.
This page will include a protection script handling login/logout.

At this page is a logout button.
This will call the protection script to handle logout.
But when logout is done, and visitor is sent back,
he will be presented with a login page. At where he just logged out from.

I have written such a protection script. It is one line of PHP at the top of code, to protect.

To fix this issue, I had to save REFERING PAGE in SESSION.
That is The Page that user was BEFORE the protected page.
When logout is done send user to this.
If no referal, then send user the default index page.

cretaceous
09-26-2007, 06:45 AM
i just checked a site I am building (shows entry boxes when not logged in - shows log out when logged in) and if I log out and then hit the back button I stay logged out - dont know what your script does but mine works - no Ajax

What I am doing is, on log in, build a session basket to hold log in details (I dont store everything so you cant actually log in from a crashed session), then on log out destroy the session - check for session at top of each page and tada, it does what you want

blackhorse
09-26-2007, 08:10 PM
I did this for the "continue shopping" instead of continue shopping always go back to the default index. use session to remember the last list products page the user was on, and bring them back to the list products page exactly.

hi.
Another issue is the following case:

Say a person is on a protected page, only for logged in users.
This page will include a protection script handling login/logout.

At this page is a logout button.
This will call the protection script to handle logout.
But when logout is done, and visitor is sent back,
he will be presented with a login page. At where he just logged out from.

I have written such a protection script. It is one line of PHP at the top of code, to protect.

To fix this issue, I had to save REFERING PAGE in SESSION.
That is The Page that user was BEFORE the protected page.
When logout is done send user to this.
If no referal, then send user the default index page.

blackhorse
09-26-2007, 08:16 PM
i just checked a site I am building (shows entry boxes when not logged in - shows log out when logged in) and if I log out and then hit the back button I stay logged out - dont know what your script does but mine works - no Ajax

What I am doing is, on log in, build a session basket to hold log in details (I dont store everything so you cant actually log in from a crashed session), then on log out destroy the session - check for session at top of each page and tada, it does what you want

You didn't keep the cache, so it was not a problem. I am going to head to this road too, if large percent of the site are not static contents and the extra traffic is not a big issue. No cache, force the reload every time. The button then will be showing the right status you are in.

halojoy
09-26-2007, 08:17 PM
I did this for the "continue shopping" instead of continue shopping always go back to the default index. use session to remember the last list products page the user was on, and bring them back to the list products page exactly.My page protection script is a bit different than a normal website authentication.

The easy way is not bad.
It will always work to send user to HOME after logout.
And we save us a lot of headache, when coding.

:)

cretaceous
09-27-2007, 06:17 AM
You didn't keep the cache, so it was not a problem. ..

OK but I havent set any directive explicitly to deal with the cache - could you explain where you believe I have done this?

It works on my localhost pc and on a webserver and on different end clients

blackhorse
09-27-2007, 11:23 AM
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="no-cache">
<meta http-equiv="Expires" content="-1">
<meta http-equiv="Cache-Control" content="no-cache">

Or use the php header to set up no cache

<?php
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header ("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
// always modified
header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header ("Pragma: no-cache"); // HTTP/1.0
?>

cretaceous
09-27-2007, 11:42 AM
yes but you dont seem to understand - I am not asking how to do it
I am asking why you are convinced I have no caching

I do not have any expiry or pragma settings at the top of my html

when the session is destroyed it destroys the session cookie - if you go 'back' there is no session cookie to be found - so it works without any cache limitations

maybe you tried but didnt completely destroy the session or the cached page is picking up variables from the session that may have been exposed

blackhorse
09-27-2007, 02:09 PM
OK, then my question, you use php session? If your page is cached, then back button to it will not require reload from the server. So no php will be involved. Just cached page will be used with the old button, right?

If you use javascript session (I am not familiar with that) or some other simple client side solutions not ajax, then you may have the answer for my problem.

Even google has the problem I addressed.

You can try it on google. Go to google homepage sign in with Gmail account. And the google header bar will show button "sign out", and browse in google for a few pages, sign out, the button will show "sign in". Back button to the previous pages, it will still show the old button "sign out" not the new button "sign in".

halojoy
09-27-2007, 09:47 PM
Only way is to turn OFF caching of pages - history, temporary internet files.

But will the browser listen to a no-cache command?
I think this is not so. Not always.

Anyway, whatever the history page shows, you are actually LOGGED OUT.
So you will not be able to get any un-authorized dynamic content. Transfered.

This issue shows, why it is a good thing to empty cached pages, before you leave your PC.
At least if there are others that use same PC. And if there is stuff that is very personal to you.

cretaceous
09-28-2007, 05:51 AM
yes - I apologise Blackhorse - because my site does a redirect via an intermediate script it is hard to hit the back button quickly enough - but when multiple clicks are achieved I can get back to the logged in state