Every time I reload the page, I get a new value out of session()->getId().
Some have suggested adding the laravel_session to the unencrypted cookie exception, but this does not fix it and is not a viable option anyway.
The issue persists no matter which session storage method I use. File, redis, etc all have the same problem.
This is happening on a fresh install of Laravel 7.
Contents of .env:
SESSION_DRIVER=redis
SESSION_LIFETIME=1440
SESSION_DOMAIN=example.test
What's causing this?
That means:
Session driver is not starting up properly
Client you're using to connect to laravel app server does not accept cookies
Cookies are set up for wrong domain and/or path.
For case 1 make sure StartSession middleware exists in app/Kernel.php at $middlewareGroups -> web
For case 3 check this answer. In case your app relies on a single domain/path, I recommend you to remove SESSION_DOMAIN.
Finally, manually remove all sessions from your session driver, then run php artisan config:cache and try again.
Related
I update my .env file using a function in my controller.
After I save the settings I need to update, I call Artisan::call('config:cache') to clear the cache of my site's configuration.
Everything works fine on localhost, but when I try to clear config cache on production, it doesn't work. (No warnings or errors.)
I even tried with --no-interaction option attached to this CLI command.
Did anyone have this problem and know what causes it?
check into the PHP security settings and make sure you can run these exec,passthru,shell_exec functions in your server.
I use docker as my local dev environment and use the dinghy-http-proxy which adds a new TLD .docker to map request to a nginx-proxy container.
My websites are typically reached through an URL like http://devel.domain.com.docker.
I want to use ngrok to develop locally while accessing remote webhooks.
I successfully launched ngrok with the command:
ngrok http -host-header=rewrite devel.domain.com.docker 80
I can access the login form of my web application through the address http://randomsubdomain.ngrok.io.
However, I can't log in because it looks like the cookie session can't be set.
Indeed, cookies sessions are tried to be set for the domain devel.domain.com.docker but as we use randomsubdomain.ngrok.io in the browser they are blocked for security reasons.
How can I bypass this problem? Am I missing something in my configuration? Is ngrok the right tool for what I want to achieve?
Asked directly to ngrok.io support and got this answer:
No, you're not missing anything, that's just an unfortunate side effect of rewriting the host header. Host header rewriting only works for some applications because of complications like this (and others that involve javascript and cross-origin, etc). If possible, it's always much better to reconfigure your website to accept the ngrok.io host header.
However, I found a solution by checking if the request contains in the header x-original-host the domain ngrok.io, and then I alter the session mechanism (in PHP session_set_cookie_params) to use the x-original-host domain instead.
As mperrin said you have to alter php cookie session mechanism.
Reading from session_set_cookie_params:
Set cookie parameters defined in the php.ini file.
The effect of this function only lasts for the duration of the script.
Thus, you need to call session_set_cookie_params() for every request
and before session_start() is called.
The most important argument is $domain and to make ngrok work equally decent you can also use before session_start() the command ini_set() (see ini_set): ini_set('session.cookie_domain', 'xxx.ngrok.io');
It also took me hours to resolve for my custom hosting php platform but I knew that my auth subsystem should work under a valid hostname apart from localhost so I focused in how the cookies are set from my code.
Such kind of php environment settings should be set early by any decent php framework and that was one of my primary goals when I started building it (in my case I only have to change the value in a json text file at the server).
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 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
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