I'm using Zend Framework for PHP and handling sessions with the Zend_Session module. This is what I have in my Initializer (or bootstrap):
Zend_Session::start();
Zend_Session::rememberMe(864000);
864000 seconds should be good for 10 days, but I'm still being kicked out at about an hour (or maybe a little less). I've tested to see if this statement works at all by setting it to 10 seconds, and indeed I am kicked out at the appropriate time, but when I set it to a very high value, it doesn't work! I went through some of the documentation here:
http://framework.zend.com/manual/en/zend.session.html
Another method I saw was to use the following:
$authSession = new Zend_Session_Namespace('Zend_Auth');
$authSession->setExpirationSeconds(3600);
Now, I have different namespaces. Does this mean I have to set this for all of them if I want to keep them from expiring? I haven't tested this method of setting the expiration, but I really wanted to see what the gurus on here had to say about what the correct way of approaching this problem is. Thanks a lot guys...
Also, does anyone know how I can make it so that the session never expires? I've tried setting the second to 0 and -1, but that throws an error.
I had the same problem and solved it by putting:
resources.session.save_path = APPLICATION_PATH "/../data/session/"
resources.session.gc_maxlifetime = 864000
resources.session.remember_me_seconds = 864000
in the application.ini (as suggested by tawfekov) and
protected function _initSessions() {
$this->bootstrap('session');
}
in the Bootstrap.php (this I typically forgot at first). You have to give the session directory the correct access rights (chmod 777). I described the issue here. Hopefully this will help the next person with the same issue.
Your client's computer clock, date, AND time zone need to be set correctly for session expirations to work. Otherwise the time conversions are off, and likely causing your cookie to expire the minute it hits the their browser.
Try calling remember me before starting the session:
Zend_Session::rememberMe(864000);
Zend_Session::start();
Otherwise I believe it will use the default of remember_me_seconds. See 49.4.4. rememberMe(integer $seconds)
Also, does anyone know how I can make
it so that the session never expires?
I've tried setting the second to 0 and
-1, but that throws an error.
I don't think that is possible. The session is controlled by whether the cookie exists on the users computer. Those cookies can be deleted, even by the users if they clear their cache. I think the best you can do is set it to a very large number. Say 12 months.
I guess you are using ZF 1.8 or above ,
so you can put in the config.ini file
resources.session.save_path = APPLICATION_PATH "/../data/session"
resources.session.remember_me_seconds = 864000
and these setting will automatically loaded
again only in ZF 1.8 or above if not you had to load these config manually
i hope it helps you :)
Are there other PHP applications running on the server?
Assuming you're using the standard, file-based, session handler, PHP will store all sessions in the same place (typically /tmp).
If you have some other script on the server using the default session_gc_maxlifetime settings, it may be eating your session files.
The easiest fix to try is to configure PHP to store session files for this application someplace special -- that way other apps running on the server will never accidently "clean up" session data from this app.
Try creating a directory like /tmp/myAppPhpSessions (or whatever), and adding:
ini_set('session.save_path','/tmp/myAppPhpSessions');
ini_set('session.gc_maxlifetime', 864000);
at the very top of your bootstrap file.
Make sure session.auto_start is off in php.ini
Related
I have a very critical issue with my Magento store. The session gets reset on every HTTP request, for example if I refresh the homepage it creates a new session.
Initially I thought it was from the php.ini settings but I set session.cookie_lifetime = 86400 ni my php.ini file and from magento backend as ewll. Then I also moved the session from files to db to try and resolve the problem but it keeps creating new sessions on every request. As a result of this I can't add any items to the cart or do anything else because my session gets destroyed every time.
I solved this issue by enabling "Use SID on Frontend" in 'system->web->session validation settings'.
Hope the following will helps you.
https://magento.stackexchange.com/questions/385/cart-dropping-all-items-cart-session-clears
I found the issue and located it in this file:
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
In order to fix it more elegantly one should override the specified file in the local code pool insted of modifying the core directly. Like below:
app/code/local/Mage/Core/Model/Session/Abstract/Varien.php
Also for the above to work php.ini setting session.cookie_secure must be commented or set to 0.
Make sure to check your php.ini
I had a similar problem and noticed that the .ini was trying to set a different save path for the sessions then Magento.
In short edit php.ini and comment out the save_path and cookie_secure:
;session.save_path =
;session.cookie_secure =
I'm sure there is a way in Magento to set the secure cookie param, as I would not want to suggest anything that maybe a security risk.
Then restart php or apache
I just move my Magento store to my localhost environment for testing use, I also using Git to maintain code, but after I move all the files to my local environment, I can't login my admin page, but I can still see my frontend pages, and the git, the database, seems works well.
When I type a wrong admin/password to my admin page, it still gives me "Invalid password".
But when I enter the right one, it just refresh the page and stay at the login page, nothing happens.
Does anyone has met this problem before? Has any ideas?
Thanks in advance!
Although this question is old, all the above answers did not work for me until I did one additional thing.
Follow the very helpful answers already posted (summary):
Change your base_url to http://127.0.0.1/ for secure and unsecure path.
delete files in var/session and var/cache
alter your Varien.php file accordingly - depending on your version of Magento.
And then:
Finally, use http://127.0.0.1/your/site/folder/name/index.php/admin
It was the lack of the index.php/admin ( instead of using http://127.0.0.1/site/admin ).
I hope this helps someone else.
Recently started using Magento for a project and came across this issue. I was left frustrated by the fact there are at least ten or more different workarounds suggested on the net and it took a bunch of trial and error to find one that did the job. Seemingly some workarounds work for some versions and not for others. No one explained why or how the problem occurs and the most popular solutions involve hacking the code base or using a different url, which shouldn't be necessary.
The cleanest solution I found for Community Edition 1.9.1.1 was editing two config values in the database:
update core_config_data set value = NULL where path = "web/cookie/cookie_path";
update core_config_data set value = 0 where path = "web/cookie/cookie_httponly";
The cookie path is actually NULL by default on a fresh installation but it must either be NULL or empty string.
The behavior arises because some browsers including Chrome have issues creating cookies with a localhost domain, this means that when Magento calls session_start() the session identifier cookie never gets created and as a result information can not be passed from page to page. The login procedure is actually successful but the next request doesn't know about it, hence why you get redirected back to the login screen. There are no errors because Magento doesn't account for this edge case as a possibility.
If you do not provide a domain value when creating a cookie on localhost then the browser has no problem with it. Unfortunately just setting web/cookie/cookie_path to NULL is insufficient, because Magento's configuration class resolves this as an empty string which is enough for a real domain to be set later in the code:
if (isset($cookieParams['domain'])) {
$cookieParams['domain'] = $cookie->getDomain();
}
This method eventually uses the current HTTP host to resolve a real domain for the cookie, and the browser therefore wants nothing to do with it. However if we disable web/cookie/cookie_httponly then Magento will not perform this additional step, $cookieParams['domain'] is unset and no domain gets passed as a session parameter, thus allowing the session cookie to be created and things to function as they should.
Note that any time you modify the database configuration you must delete the contents of /var/cache/ for the changes to be reflected.
If like me you don't want to have to comment out code, or even make configuration changes, then I created an extension which overrides the getDomain() method shown above and returns null if we are on localhost, this should be somewhat more future proof and result in no collateral damage.
http://www.mediafire.com/download/q39p4k95s5tlght/LocalCookie.zip
Try deleting the contents of the cache folder /var/cache. Clear your browser cookies and try. Also, if you have copied down the database from your server, you may need to manually change the base urls (secure and non secure) as well as the cookie domain in the core_config_data table. Do this manually if you need to. e.g. web/unsecure/base_url with production value of http://www.mywebsite.com/ becomes "http://localhost/"
When ever I have had this it's because of this or cache. Ensure the cache folder is ignored in git hub if it's not already.
1.you need remove the cache
rm -rf var/cache/* var/session/*
2.change the domain form core_config_data
update core_config_data set value="http://127.0.0.1/" where path="web/unsecure/base_url";
update core_config_data set value="http://127.0.0.1/" where path="web/secure/base_url";
do these steps :
1: go through: xampp\htdocs\magento\app\code\core\Mage\Core\Model\Session\Abstract**
2: open **Varien.php file
3: make comment line number from 87 to 104 save it and try to login...
Had the same issue, but the fix was changing DB values:
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/unsecure/base_url';
UPDATE `core_config_data` SET `value` = 'http://127.0.0.1/example/' WHERE `path` = 'web/secure/base_url';
Then in browser http://127.0.0.1/example/admin
Same problem! I fix my problem after remove/replace static domain in core_config_data Table
web/secure/base_url
web/secure/base_link_url
web/secure/base_skin_url
web/secure/base_media_url
For me, running it on IIS (I know, not officially supported):
Although other suggestions kind of worked I found the best solution was to enter a new A record for me domain like
127.0.0.1 local.example.com
Then in IIS add the binding
local.example.com
to my site and it worked perfectly.
I found there were errors when actually trying to login to the customer account more than admin but believe it still applies.
i already posted this question but still wasnt able to resolve this issue.
seems that everyone has this problem with codeigniter .
When i set my session in a controller it works perfectly and i can display it.
WHen i move to another controller, the (CUSTOM) session data is completely lost.
i tried changing my cookie_domain in config.php. Since i am on localhost i tried localhost with without / and localhost/codeigniter and sodeigniter all did not work. i am lost
btw, i read somewhere that this happens when 2 ajax requests happen at the same time. could that be the problem?
Or maybe tell me how you resolved the problem if you had same issues
screw this, i am swithing to php native sessions. if anyone wants to do that,
http://codeigniter.com/wiki/PHPSession
Check and double-check your code or any external libraries you are using for a stray sess_destroy(). I ran into a similar problem where I was storing an id in the session for reference but if the user then logs in the SimpleLogin library I was using for logins just destroys the entire session including data I did not want to lose.
This is what I get for not writing my own code.
I have magento installed in a subdirectory. www.domain.com/subdir/magento
This site worked perfectly at one point. I changed nothing, until my client said he couldn't login to magento admin.
I logged in just fine from my computer, but on his computer it just redirected back to the magento admin login without an error message and a url that looked goofy like this:
http://domain.com/subdir/magento/index.php/admin/index/index/key/3097210b826ac4a86d7531cb4089c9d0/
I thought that his cookies were being blocked, but that was not the case.
My magento settings were secure/unsecure baseurl: http://domain.com/subdir/magento/
web cookie path: (blank)
web cookie domain: (blank)
After clearing out var/cache, I found that I myself could not login to the admin either, with the same exact issue.
I tried the following settings without luck:
path: /
domain: domain.com
path: /subdir/magento
domain: vigrond.com
I also tried commenting out those lines in Varien.php, but that had no effect either.
My server account is a VPS and it has plenty of free space.
So I'm pretty much lost, wondering why this happened in the first place when it worked before (didn't change anything), and why it's so complicated?
Any help appreciated
If a login error message ("invalid password", etc.) isn't being displayed it's almost always a session cookie problem. In order to rule it our entirely, use Use your browser's cookie viewer and/or your favorite HTTP traffic sniffer and check
That all the cookies have proper expiration dates after being set
That the session cookie has a consistent token name/value for each request
That PHP, when running through Magento, has the various session lifetime ini settings at a reasonable value
That PHP can write to whatever it's using as a cookie storage medium
That the server's time matches the real time, and that PHP itself has a timezone set
Find app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. in your Magento install folder. Comment out the lines (see below) 80 to 83. The line number may vary.
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()//,
//dependes which versin of mage you are using, you may comment these as well
//$this->getCookie()->getDomain(),
//$this->getCookie()->isSecure(),
//$this->getCookie()->getHttponly()
);
This is caching issue. Which recently Magento community confirmed that is sorted but it is not. :)
Just clear your cache and do this steps it should work anyway.
Comment this lines also
// if (!$cookieParams['httponly']) {
// unset($cookieParams['httponly']);
// if (!$cookieParams['secure']) {
// unset($cookieParams['secure']);
// if (!$cookieParams['domain']) {
// unset($cookieParams['domain']);
// }
// }
// }
//
// if (isset($cookieParams['domain'])) {
// $cookieParams['domain'] = $cookie->getDomain();
// }
Make sure you have cookies enabled in your browser, try a number of
different browsers including Safari or Opera. Chrome will give some
problems and you need to remember to clear you cache in Chrome after
making changes!
Make sure you file permissions are set to EVERYONE - FULL CONTROL for Windows and 777 for your Mac/Linux environment If all that still doesn’t work you can try this: (I do not recommend this solution for a production version of Magento, but for you local test enviroment this will work.)
Check the version of php you are using. If you are using recent Magento try to find which version of PHP and extensions requires.
More details
Did you erase the session storage in var directory?
In my case, when I was playing with autorization for multistore on subdomains (changed path and domain for cookie as you did), this method helped me to drop the "bad" cookie and sucessfuly logined in admin:
In apppath/var/session directory I've made command in shell (be careful with path, this could delete all the files in the directory)
rm -rf /path/to/magento/var/session/*
And then just clean the cookie for domain in browser.
I was fighting with this issue today on my local server. I couldn't login using any browser. I really didn't want to comment out any lines in core files or doing any other "dirty" solutions.
Firstly I checked cookie set by browser. It had expiration set to 1970, so clearly it was a cookie problem.
I checked values for cookies in magento database. In phpmyadmin I found table core_config_data, then fields with values : web/cookie/cookie_domain and web/cookie/cookie_path. They were both blank.
My solution was to set:
web/cookie/cookie_domain to my domain name
and
web/cookie/cookie_path to /.
Example:
your domain where you run magento is magento.local
set:
web/cookie/cookie_domain = magento.local
and
web/cookie/cookie_path = /
I never resolved the issue. But I wiped the clients computer and reinstalled windows 7, and it worked. It was very strange that it didnt work before as he was not behind a proxy, did not have ad ons or viruses. And the issue reproduced in each of his browsers (chrome firefox and IE). It was not a router issue. It was a windows issue, but I couldn't tell you what exactly was causing it. It was not the internet security settings either, as I checked those. Also checked the host file. As I said before, very baffling
I had the same problem, but I was working on XAMPP on windows 7 x64.
In Magento system - configuration - web - session cookie management change Use HTTP Only to no and Cookie Lifetime to 86400.
I only changed the Cookie Lifetime just in case of daylight saving time may not have to be changed.
Before the changes I could only login using Firefox and after the changes all browsers work.
Leave Cookie Path and Cookie Domain blank.
Check the cookie configs in core_config_data table and check if your session is being saved on db. In my case, someone just changed the cookie domain and the cookie path with a wrong value.
You can also check this on the node in your app/etc/local.xml.
If it's on db, maybe you should change do files to be able to clean the session data directly on var/session dir.
Delete cookies (related to your domain) from your browser setting.
I was facing the same issue and at the end i found that it was due to full disk space and due to this Magento was not able to create sessions file in the var var/session folder. After cleaning up log files that issue was resolved.
Also, you can update the password in the database if everything else from above didn't work and you need desperate access:
UPDATE admin_user SET password=CONCAT(MD5('qXpassword'), ':qX') WHERE username=‘user’;
replace user and password words according to your needs.
If nothing works, make sure the disk quota is not exceeded. The new session cookies created under ./var/session will be zero bytes length if disk quota for the user is exceeded.
In Case, that you dont see any cookie named "frontend" or "adminhtml", when you reload the page, the Magento cookie wasn't set. In my case I have a wrong cookie_domain.
I used "null" instead of "NULL".
As I set my cookie_domain to NULL in core_config_data, the problem was solved
We have an internal control panel that all employees in the office are logged into all day, including customer service. I'd like for it to be setup so that it keeps you logged in for 1 hour before your session expires. How can I change this in the PHP.ini? I made a change before I understood would keep the session open until the browser window was closed but it didn't stick.
There are two different values you can set:
session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up.
and session.cookie_lifetime which is how long the cookie will last.
http://www.php.net/manual/en/session.configuration.php
both values can be set in the php.ini file, but might get overriden in .htaccess files or in your scripts using ini_set.
You can also do this client-side using JavaScript. Use an AJAX call to periodically 'check-in' with the server, keeping the PHP session alive. You can also monitor if the user is doing anything on the current page, show them a '2 minute warning' message, or even redirect them to a 'session terminated' page when the 1 hour inactivity period is reached. You could even use this to 'force' a user to be signed out.
This isn't as secure as doing it purely in PHP, but does give you more flexibility to build cool features.
The most secure place to implement this would be in your application. You can store the session update time in $_SESSION on each page load. Before you update it, you check if it has exceeded the 60 minute limit, in which case you can use session_destroy() to terminate the session, followed by a redirect to the login page (or similar).
I don't think this can be done from the php.ini file. I think you either want to store the login time on the server and compare that with the current time and delete if 60mins have passed, or alternatively, use cookies -- these can have an explicit lifespan. See this for more information on cookies.