This object is in archive!
Login - Remember Me functionality
Hi there. It seems that the "Remember me for 14 Days" functionality is not working. Is this a configuration issue on my part or a possible bug?
Hi there. It seems that the "Remember me for 14 Days" functionality is not working. Is this a configuration issue on my part or a possible bug?
In your case in PHP settings you need to set to 0 or increase the following paramter:
Also there are parameters in php.ini to pay attention - session.gc_maxlifetime and session.cookie_lifetime
In your case in PHP settings you need to set to 0 or increase the following paramter:
Also there are parameters in php.ini to pay attention - session.gc_maxlifetime and session.cookie_lifetime
Just an update on this - it works for a little while... (about an hour?)
Just an update on this - it works for a little while... (about an hour?)
Make sure that you have in application/configs/bootstrap.inc all "lifetime" parameters to be 864000
Make sure that you have in application/configs/bootstrap.inc all "lifetime" parameters to be 864000
I guess, if you also use Facebook login, Remember me won't work, other than just using standard authentication process. As of now, we can't identify the problem
I guess, if you also use Facebook login, Remember me won't work, other than just using standard authentication process. As of now, we can't identify the problem
In your case in PHP settings you need to set to 0 or increase the following paramter:
Also there are parameters in php.ini to pay attention - session.gc_maxlifetime and session.cookie_lifetime
In your case in PHP settings you need to set to 0 or increase the following paramter:
Also there are parameters in php.ini to pay attention - session.gc_maxlifetime and session.cookie_lifetime
Hi Stas. I'm confused about the "official answer" on this topic.
The specific 3 php.ini PHP settings that you mention are the same on both our servers. I just verified them, we have these values set to the standard that comes with PHP.
We have many WordPress installations, and when I login to all of those, I click "remember me" and it remembers me for weeks.
However with UseResponse all our visitors are reporting the same problem we see - I have to login again every time I come to the site.
So I think this is something to fix on the UseResponse side, instead of changing our PHP settings that impact all our WordPress sites too which are already working fine.
Please advise what could be causing this to work fine for WordPress but not for UseResponse. :-)
Thanks!
Hi Stas. I'm confused about the "official answer" on this topic.
The specific 3 php.ini PHP settings that you mention are the same on both our servers. I just verified them, we have these values set to the standard that comes with PHP.
We have many WordPress installations, and when I login to all of those, I click "remember me" and it remembers me for weeks.
However with UseResponse all our visitors are reporting the same problem we see - I have to login again every time I come to the site.
So I think this is something to fix on the UseResponse side, instead of changing our PHP settings that impact all our WordPress sites too which are already working fine.
Please advise what could be causing this to work fine for WordPress but not for UseResponse. :-)
Thanks!
I have tested this one more time again with different browsers and all of them remembering me as I want. Remember me session will close after deleting cookies or if php unable to find session file on server-side. The second case is your case. In ohter words session lifetime is low or system handler forced to clean session directory.
Wordpress uses insecure remembering method that stores current user password hash value in browser cookie. Each time when user reloads blog pages Wordpress checks for this hash variable on clien-side to identify user. This way is insecure because cookies may be stolen and used to login to user's account. Therefore we have refused such method to remember user's login status.
I have tested this one more time again with different browsers and all of them remembering me as I want. Remember me session will close after deleting cookies or if php unable to find session file on server-side. The second case is your case. In ohter words session lifetime is low or system handler forced to clean session directory.
Wordpress uses insecure remembering method that stores current user password hash value in browser cookie. Each time when user reloads blog pages Wordpress checks for this hash variable on clien-side to identify user. This way is insecure because cookies may be stolen and used to login to user's account. Therefore we have refused such method to remember user's login status.
Hi Paul. thank you for your answer, but this does not answer my question. :-)
Just to clarify - I understand that it works for you in your test, but that is after you made changes to your php.ini for this.My question is this: our php.ini settings are the standard default that come with Apache/PHP. It works for everything else. For example, how come logging into all my wordpress sites remembers me fine with our current - and default - settings in php.ini on our servers... But with UseResponse I have to change PHP settings for it to remember me?
Thanks!
Hi Paul. thank you for your answer, but this does not answer my question. :-)
Just to clarify - I understand that it works for you in your test, but that is after you made changes to your php.ini for this.My question is this: our php.ini settings are the standard default that come with Apache/PHP. It works for everything else. For example, how come logging into all my wordpress sites remembers me fine with our current - and default - settings in php.ini on our servers... But with UseResponse I have to change PHP settings for it to remember me?
Thanks!
In Wordpress all passwords are stored in cookies hashed, but it's not secure, so we made UR to store password in sessions which is more secure as we value it. You can read some facts for more info about storing passwords in cookies.
In your case, your session is timed out or cleaned due to some environment specifics.So you need to change php.ini settings in order it to work that won't affect anything on your server or other products.
In Wordpress all passwords are stored in cookies hashed, but it's not secure, so we made UR to store password in sessions which is more secure as we value it. You can read some facts for more info about storing passwords in cookies.
In your case, your session is timed out or cleaned due to some environment specifics.So you need to change php.ini settings in order it to work that won't affect anything on your server or other products.
Hi Stas!
OK, thank you for the help, sorry to be difficult. :-)
Thanks for the explanation, that's helpful. OK, I requested our web host to change this parameter session.cache_expire to "0".That seemed to help, but did not seem to fix it. I can now login, then close my browser complete, then open it again and I'm still logged in. Also I can go to another site, then come back in an hour, and still logged in. But if I wait a few hours, I am no longer logged in.Is there something else we need to change? You mentioned in official answer a few more php.ini parameters but did not specify what to change them to. Currently here's how they are set, as per Apache/PHP defaults: -----
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0
Hi Stas!
OK, thank you for the help, sorry to be difficult. :-)
Thanks for the explanation, that's helpful. OK, I requested our web host to change this parameter session.cache_expire to "0".That seemed to help, but did not seem to fix it. I can now login, then close my browser complete, then open it again and I'm still logged in. Also I can go to another site, then come back in an hour, and still logged in. But if I wait a few hours, I am no longer logged in.Is there something else we need to change? You mentioned in official answer a few more php.ini parameters but did not specify what to change them to. Currently here's how they are set, as per Apache/PHP defaults: -----
; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440
; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0
Dan,
Directive session.cookie_lifetime sould be 1209600 not zero.
Try to change session.cookie_lifetime only if it doesn't help, then try to change session.gc_maxlifetime to 864000.
We have never seen this problem before, you are the first customer with such problem. I think this raises because of non-standard server configuration you are hosted on.
Dan,
Directive session.cookie_lifetime sould be 1209600 not zero.
Try to change session.cookie_lifetime only if it doesn't help, then try to change session.gc_maxlifetime to 864000.
We have never seen this problem before, you are the first customer with such problem. I think this raises because of non-standard server configuration you are hosted on.
Hey Paul.
Great news! After a few days I can confirm this is now working.
I am pretty sure our server configuration is standard Apache/PHP. We have 2 servers and both came pre-configured from our web host the same way.
See the reference doc from php.net - both values we had set are the PHP default: http://php.net/manual/en/session.configuration.php
I'm just glad to have it working - You guys may want to have this requirement documented for folks in the future. :-)
Hey Paul.
Great news! After a few days I can confirm this is now working.
I am pretty sure our server configuration is standard Apache/PHP. We have 2 servers and both came pre-configured from our web host the same way.
See the reference doc from php.net - both values we had set are the PHP default: http://php.net/manual/en/session.configuration.php
I'm just glad to have it working - You guys may want to have this requirement documented for folks in the future. :-)
Dan,
We redefine this parameter in config file, but your hosting doesn't allow that, so this requirement is not strict, and others don't have problems with that, so it's custom situation.
Glad that it worked for you.
Dan,
We redefine this parameter in config file, but your hosting doesn't allow that, so this requirement is not strict, and others don't have problems with that, so it's custom situation.
Glad that it worked for you.
Understood, thanks so much Stas. And thank you and Paul for your patience and all your help!! :-)
Understood, thanks so much Stas. And thank you and Paul for your patience and all your help!! :-)
Hey Stas!
Could you tell me in what UseResponse config file this parameter is defined in? is it in .htaccess? Don't see it there...
That way I can reach out to my web hosting folks and ask their help to make it work for only this particular website, instead of having to change the server-wide php.ini file.
This didn't really matter before when the UseResponse installs were on their own server, but now that we're migrating the UseResponse installs to our REALLY high traffic server, I want to limit this really high "session.gc_maxlifetime" php setting to just the UseResponse websites if possible. :-)
Thanks!!
Hey Stas!
Could you tell me in what UseResponse config file this parameter is defined in? is it in .htaccess? Don't see it there...
That way I can reach out to my web hosting folks and ask their help to make it work for only this particular website, instead of having to change the server-wide php.ini file.
This didn't really matter before when the UseResponse installs were on their own server, but now that we're migrating the UseResponse installs to our REALLY high traffic server, I want to limit this really high "session.gc_maxlifetime" php setting to just the UseResponse websites if possible. :-)
Thanks!!
Hi, Dan.
I guess that "session.gc_maxlifetime" directive changing is not allowed via .htaccess.
If you have access to php.ini on your server try to change "session.gc_maxlifetime" value to 1440 - this is optimized default value in most cases.
Also, I would recomend you not to change "session.cookie_lifetime" to prevent proleptic end of the session.
Hi, Dan.
I guess that "session.gc_maxlifetime" directive changing is not allowed via .htaccess.
If you have access to php.ini on your server try to change "session.gc_maxlifetime" value to 1440 - this is optimized default value in most cases.
Also, I would recomend you not to change "session.cookie_lifetime" to prevent proleptic end of the session.
Hey Paul, OK let's figure this out together.
Here's my public_html/.htaccess file for the UR websites - http://www.screencast.com/t/DBeqzBV4cy
Note there is no "session.gc_maxlifetime" in it, no PHP directives at all.
Here's my session settings in the system main php.ini - http://www.screencast.com/t/nyoyOcVz3rOB
I DO know that the UR application is setting some PHP session vars correctly, because the system default for session files is /tmp/, but the UR website session files are being correctly overridden in UR to be in application/sessions/
The problem I'm trying to solve is the very high gc_maxlifetime in the main php.ini, since it applies to all my hight traffic sites too, but we only need it for the UR sites. Regular sites work fine with default 1440 value.
Re: session.cookie_lifetime - should I set this back to "0"? That was one of the first things i tried to fix the UR premature logout from that other support thread. But that didn't fix it - only changing gc_maxlifetime solved the problem. :-)
But I thought that if this value is "0", then if the person logged into the UseResponse website closes their browser, won't they need to login again?
So - please tell me please exactly what to change in the system main php.ini and what to put in any other files specifically for the UR websites, like .htaccess and I'll do it. :-)
Hey Paul, OK let's figure this out together.
Here's my public_html/.htaccess file for the UR websites - http://www.screencast.com/t/DBeqzBV4cy
Note there is no "session.gc_maxlifetime" in it, no PHP directives at all.
Here's my session settings in the system main php.ini - http://www.screencast.com/t/nyoyOcVz3rOB
I DO know that the UR application is setting some PHP session vars correctly, because the system default for session files is /tmp/, but the UR website session files are being correctly overridden in UR to be in application/sessions/
The problem I'm trying to solve is the very high gc_maxlifetime in the main php.ini, since it applies to all my hight traffic sites too, but we only need it for the UR sites. Regular sites work fine with default 1440 value.
Re: session.cookie_lifetime - should I set this back to "0"? That was one of the first things i tried to fix the UR premature logout from that other support thread. But that didn't fix it - only changing gc_maxlifetime solved the problem. :-)
But I thought that if this value is "0", then if the person logged into the UseResponse website closes their browser, won't they need to login again?
So - please tell me please exactly what to change in the system main php.ini and what to put in any other files specifically for the UR websites, like .htaccess and I'll do it. :-)
Dan,
At first apply my suggest on https://help.useresponse.com/responses/huge-number-of-session-files#comment-1339 . Maybe this tip will resolve your problem. If not we will continue to pick up solutions.
Dan,
At first apply my suggest on https://help.useresponse.com/responses/huge-number-of-session-files#comment-1339 . Maybe this tip will resolve your problem. If not we will continue to pick up solutions.
Quick Update: we've completely rebuilt Remember Me feature in UseResponse 3.0, so it will work without any connection with server PHP settings.
Quick Update: we've completely rebuilt Remember Me feature in UseResponse 3.0, so it will work without any connection with server PHP settings.
Stas, that is wonderful news! we're very excited to see 3.0!!! this is almost as welcome as removing the requirement for that zend encoder a while back. :-) Do you have a tentative planned release date?
Stas, that is wonderful news! we're very excited to see 3.0!!! this is almost as welcome as removing the requirement for that zend encoder a while back. :-) Do you have a tentative planned release date?
Hello Dan,
Very hard to give exact date, but we hopefully to launch beta in January-February the latest as we've brought about +100 new features and completely rebuilt core. Now we are working on Knowledge Base.
Beta will be released without mobile interface and API.
Hello Dan,
Very hard to give exact date, but we hopefully to launch beta in January-February the latest as we've brought about +100 new features and completely rebuilt core. Now we are working on Knowledge Base.
Beta will be released without mobile interface and API.
Hello guys,
Do you know how to implement the keep me logged in functionality in oracle forms
Hello guys,
Do you know how to implement the keep me logged in functionality in oracle forms
Hello Gladys,
Sorry, but we don't know about oracle forms and it's out of UseResponse software
Hello Gladys,
Sorry, but we don't know about oracle forms and it's out of UseResponse software
Hello guys,
unfortunately I have to post, that "Remember me", the most annoying feature of UR 2.X for full day support, is still there even in a new version of UR 3.1.
I'm running wikipedia, two wordpress instances and one SImpleMachine forum and none of these has any problems with remember a login. So is there anything I can do, to fix this (and I do not have full access to apache server, as my web hosting is just provided space by another company). Thanks
Hello guys,
unfortunately I have to post, that "Remember me", the most annoying feature of UR 2.X for full day support, is still there even in a new version of UR 3.1.
I'm running wikipedia, two wordpress instances and one SImpleMachine forum and none of these has any problems with remember a login. So is there anything I can do, to fix this (and I do not have full access to apache server, as my web hosting is just provided space by another company). Thanks
Hello Jirka,
Were you able to resolve the issue with "remember me" on your server?
Hello Jirka,
Were you able to resolve the issue with "remember me" on your server?
Replies have been locked on this page!