Jump to content

Recommended Posts

I realise this might be a     html   answer but i expect there is a better php solution. 

 

My issue is keeping users logged into my app. (securly) 

 

this below simply refreshes the page every 200 seconds to keep the session live. 

<meta http-equiv="refresh" content="200;url=http://mywebsite/login.php" />

 

 

What i dont know (or cant find anywhere) is best practice. 

 

If a user is idol for  say 10 minutes what should happen?  

Do i keep refreshing the page. ( this seems a bit clumsy as if after 190 seconds the user starts to complete a form..the page will still refresh. 

 

What do you guys advise i do?   is this jquery, html or php solution? 

 

Ultimately i want a happy customer who doesn't come back to a site that's logged them out but doesn't tell them.  ( at moment my app looks like ( with out the meta code) they are logged in til they press another button. Then the staus changes to 'logged out' but they might not notice this and waste time filling out a form with no session

Edited by glendango
Link to comment
https://forums.phpfreaks.com/topic/306576-keeping-users-logged-in/
Share on other sites

php picked an arbitrary and short default session garbage collection maxlifetime value of 1440 seconds (24 minutes.) you will want to set this to a more reasonable value to match how your site gets used. this must be set before every session_start() statement, so you will want to set it 'globally', either in your master/local php.ini, in a .htaccess file (when php is running as a server module), or in a common 'required' configure file that all your scripts use.

 

per the note in the session.gc_maxlifetime documentation, the shortest session.gc_maxlifetime value of all the scripts being executed will be used, so if you are using shared web hosting and are using the default/common /tmp location for the session.save_path setting, you will want to set the session.save_path setting to be to a folder within your own account's directory tree, so that only your scripts will affect (and have access to) your session data files.

 

Ultimately i want a happy customer who doesn't come back to a site that's logged them out but doesn't tell them.

 

 

if you are using a session based login and someone leaves and returns to your site, your code should display the correct current state. if it doesn't, you either have a caching problem (dynamic .php pages have been cached somewhere - server, browser) or a logic problem in your code (your code isn't testing/displaying the logged in state correctly.)

Edited by mac_gyver
  • Like 1

Also you mentioned shared hosting which i have for now . 

 

When  a user adds a lead into the database it records it -7 hours gmt ( i.e. East Coast USA where the server is based)   

 

Is this ok or shoudl i be changing this in the .ini code as well to get it back to gmt time. Or is this just crap godaddy and i should use a european server?  

You can set the default timezone using date_default_timezone_set. Ideally you'd set the timezone to UTC and store all your dates in that timezone. You can use a different timezone to display the dates later by using DateTime::setTimezone if desired, such as if you wanted to convert them to your users local timezone before displaying them.

yep as always..looked at php.net and ended up 10x more confused..

i use the dateTime stamp to create the entry into the database and so dont control the 'time'.  

Does that make more sense?

 

Do i change the ini or do i script it? 

Am i right about the godaddy part as well?    this seems stupid seeing as they must have so many users in europe / uk . 

Edited by glendango

i use the dateTime stamp to create the entry into the database and so dont control the 'time'.  

Does that make more sense?

 

 

if by this, you mean the database table column type and default value or the NOW() function in a query, the database server has a timezone setting too. you would need to set it to the value you want, immediately after making the database connection.

Don't know if this question is still alive or not but here's my $.02

 

What is it that you are afraid of losing when a user is logged out? Is it simply the need for that person to login again and again? Or is there some data in your SESSION array that you want retained?

 

I use cookies extensively for my apps that have rather long expiration times on them to help my users skip the login process (myself included!). I don't have any apps that require the long-term retention of 'data' so that is new for me. Personally if it was absolutely essential to retain some data items between sessions, I would use the userid (from the login) to store that data each time I wrote out to the client and 'went away'. That way if the user does get logged out due to a cookie expiration, I can use the login user id to retrieve that stored session data.

  • 1 month later...

Sorry , just read this thread again ..thanks to all who responded. 

 

i used a meta refresh in the end so i know the  user has gone back to the login page ..chrome does a good job of retaining the log in details so users can get straight back in. 

Edited by glendango

You might want to look at "best practices" ... although that's something of a nebulous concept. I read a piece some while back about Amazon's work in this area.

 

As you may have noted, they recognize you all the time by a cookie, and only require login for "sensitive" operations. You can even add stuff to the cart if you're cookied in ... it's only at checkout you're asked to verify credentials.

 

It might be worth it to read up and put some thought into that ...

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.