PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Sun Oct 20, 2019 5:13 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: When to set a session
PostPosted: Sat May 02, 2015 12:50 pm 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 179
Hi, I don't start a PHP session until the user opens the login page or the registration page. In other words I don't start a session on the home page under the assumption that random users may land on the home page out of curiosity or accident and not be interested. I also remove the session file when the home page is opened hoping that they will click the logoff button and go back to the home page. I do this to reduce the number of session files kicking around. I have never read anything about this so it is basically my idea. Am I correct in assuming this is pretty much standard practice.

Thanks,
John


Top
 Profile  
 
PostPosted: Sat May 02, 2015 8:29 pm 
Offline
Spammer :|
User avatar

Joined: Wed Oct 15, 2008 2:35 am
Posts: 6617
Location: WA, USA
Nope. Standard practice is to have a session everywhere.

Besides, if you don't use sessions on a page, how will it know if the user is logged in?


Top
 Profile  
 
PostPosted: Sun May 03, 2015 4:49 am 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 179
What I did is when they hit the login page (post home page) I set a session variable called "Login". So most of my pages are restricted to those who are logged in and maybe 10 are not. So I will called them Restricted-Page (RP) and Free-Page (FP). So at the top of all the RPs I will test the "Login" session variable and if they are not logged in I take them to a special error page which gives them the option to go to the login page directly or go to the home page. So on the home page I have buttons that allow user to go to the FPs (a few of these can also be accessed if they have logged in but that is fine). So what I do is if they are logged in I have all close out buttons for all pages in exactly the same top right area to encourage them to log out when they finally get back to the main control page which has the log out button . If they log out it takes them to the home page and the home page removes the session file. This approach was mainly to reduce the number of session files kicking around since I didn't want them created unless a viewer of the home page decided to log in (save disk space and general unwanted clutter). I also create a "login" session entry if they come in through the forgotten password process.

So here is why I got concerned with this approach. It is something that probably will never happen but it in theory could. If they happen to log in twice (enter the home page twice so they can get to the login page) it will kill their process file (tested and it definitely does). On thinking about this I think this is actually a good thing since if they try to log in twice from the same machine it creates a problem for processing (confused session file). So maybe in the end it is better to leave it the way I have it and that special error screen that is called will tell them that they must not enter the home page twice on the same machine because it creates unexpected results (extra debugging work for me which I don't want). This page does not send me an email error message (again less emails which is good).

So far after thousands of runs through this approach it has not given me a problem and I guess maybe by explaining it hear I answered my own question. Specifically just modify the special error page that is produced so that if they try to log in via two home pages entries to tell them not to do that, why not to do that, and what to do if they happen to have done that. What I would do is tell them close out all pages and log off properly then log in again (opening only one home page this time).


Top
 Profile  
 
PostPosted: Sun May 03, 2015 6:35 am 
Offline
Spammer :|
User avatar

Joined: Wed Oct 15, 2008 2:35 am
Posts: 6617
Location: WA, USA


Top
 Profile  
 
PostPosted: Sun May 03, 2015 7:17 am 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 179


Top
 Profile  
 
PostPosted: Sun May 03, 2015 7:29 am 
Offline
Moderator
User avatar

Joined: Tue Nov 09, 2010 3:39 pm
Posts: 6425
Location: Montreal, Canada

_________________


Top
 Profile  
 
PostPosted: Sun May 03, 2015 8:39 am 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 179


Top
 Profile  
 
PostPosted: Sun May 03, 2015 12:35 pm 
Offline
Moderator
User avatar

Joined: Tue Nov 09, 2010 3:39 pm
Posts: 6425
Location: Montreal, Canada

_________________


Top
 Profile  
 
PostPosted: Sun May 03, 2015 6:45 pm 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 179
Thanks Celauran, I like your wording "Whoops. Looks like you're already logged in. Click here to go to your profile, click here to go to... whatever". I just created a to-do to review my error messages and see if I can improve them this way.

I got thinking about how to actually do this. It occurred to me that the log-out button would need to call the home page with a $_GET parameter to remove the current session and when that occurs it would not try to access the current session, otherwise it would do the test to see if they were already logged in.

I had no use for testing for session variables in the home page so I was clearing it every time rather than calling the home page with a parameter as I just mentioned (an error now that I think about it). It all came to light when a user triggered a bug in my program on Saturday. Before I contacted the user to figure out what they were doing I thought that maybe they tried to log in a second time (that could have triggered the bug and that was the only way I could think of that would have triggered it). It turned out this was not the case and they did something that was legit but I had failed to take this into account when I had made a change to the program. I fixed that oversight on Saturday but the scenario I had thought of kept bugging me and if it did not I never would have thought of the other bug mentioned in paragraph #2 above. Also if I had this "already logged in" test in my program already I would have known double login was not a possibility and I may have found the problem on my own without having to ask them what they were doing. The other thing is my program is only tested for doing one thing at a time so allowing them to operate two control pages at the same time could trigger bugs I had not expected (bad for me and for them). So the first change mentioned in paragraph #2 is a must (a fix) and the second change is just a matter of making the system more bullet proof.

Here is something new that just occurred to me as I am writing this. They may in fact want to go back to the home page to do some reading of the information there (perfectly valid and very possible since I give them lots of information but they may register before reading all of it). So the test for double login is probably best moved to the login page itself. Borrowing from your idea the message could be something like this. "Whoops. Looks like you're already logged in. Although operating two control pages at the same time may allow you to work more efficiently the program is not tested for this and you may get unexpected results.". I think it would be best to have this message picked up by the java-script when the login button is clicked (bypassing the call to the login page). So then the odds of them clicking he login button could be quite possible (It could be an autopilot reaction if they happen to log in often). Clicking the registration button should also be checked for. Oh well, lots to do - LOL.

So thanks for challenging the idea guys. You have kept me thinking about it and after 35 years of programming I have always found that pretty handy. I learned a few things that I had not thought of too.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group