For some reason, after debugging i've noticed that form_keys are valid only after i clear the cache by doing a manual rm -rf * in the var folder, clearing my browser cache and retrying the site.
I have made no changes to the core code, I've diffed it to the original 1.8.1 installation, and they are exactly the same.
The original problem I had was that customers couldn't login because I had been using a customer/persistent/login.phtml file from the 1.7.0.2 version, and had to change it to add the form_key as a hidden input element using the method shown in all other posts about the new addition of form keys in magento 1.8.1.
I had captcha enabled, and for some reason when I went to the customer login, captcha isn't displayed.
Randomly, I don't know what I did, the page refreshed, and the captcha displayed and I was able to login to the dashboard and it worked. Then I logged out, and the same problem happened, the customer logs in with the correct username/password, but is redirected to the same customer login page.
I have debugged the loginPostAction in AccountController.php from app/code/core/mage/customer/controllers, and it appears that when the form key is valid, after refreshing cache, clearing cache, in mage and the browser, it reaches if( getIsJustConfirmed == true){ go to __welcomedashboard(..) } however getIsJustConfirmed returns null or false.
I did a check to see where getIsJustConfirmed is set, and it appears in setCustomer of the Session.php inside app/code/core/mage/customer/Session.php:
public function setCustomer(Mage_Customer_Model_Customer $customer)
{
// check if customer is not confirmed
if ($customer->isConfirmationRequired()) {
if ($customer->getConfirmation()) {
return $this->_logout();
}
}
$this->_customer = $customer;
$this->setId($customer->getId());
// save customer as confirmed, if it is not
if ((!$customer->isConfirmationRequired()) && $customer->getConfirmation()) {
$customer->setConfirmation(null)->save();
$customer->setIsJustConfirmed(true);
}
return $this;
}
the first part of !$customer->isConfirmationRequired() always returns true, however $customer-->getConfirmation() returns null, so it doesn't setIsJustConfirmed(true).
As you've noticed, Magento 1.8 adds form keys to a whole lot of forms. The form key in the hidden input field needs to match the form key in your user's session. This plays havoc with any form of caching, as the form key stored in the block or full page cache is unlikely to match the user's session key.
Firstly, I'll assume you've already compared the templates you've copied into a custom theme against the base/default versions and added form keys wherever they're missing.
Then, the next suggestion is to turn all caching in Magento off (and any full page caches such as Varnish) and see if that resolves the problem. This will confirm that you're caching form keys somewhere and this is the cause of your problem.
Next, use a tool like Fabrizio's Advanced Template Hints to see if any of the templates containing a form key are being cached, either explicitly or implicitly via a parent block. If so, this is the cause of your problem, and you'll need to investigate what is causing these blocks to be cached. A stock Magento system won't cache these blocks, but a 3rd party extension might be causing it.
Finally, once the block cache is resolved, you'll need to think about full pace caching (if used). There's no easy answers here, you'll need to either not cache the affected pages in a FPC, or find a way to put the correct form key into the page after it's served.
Step-by-step, I was having the same issue. I started logging the session key output by Mage::log(Mage::getSingleton('core/session')->getFormKey()); on each page load.
Until attempting to login as a customer, the session remained consistent.
However, after attempting to log-in, I determined that the session was getting invalidated on each page load (i.e. the aforementioned logging method echoed a different form key on each page load).
This led me to the cookie. I noticed that after attempting to log in as a customer, there were two frontend cookies stored by the browser: one with .my_domain.com and another with just my_domain.com, thereby causing the invalidation.
Setting the cookie Domain under System -> Configuration -> General -> Web to my_domain.com addressed the duplicate cookie problem and the forms behaved as expected.
Related
My current Magento website is requesting a store (via lightbox) when the user first arrives on the home page. The user will continue navigating the website and content will appear properly without any issues.
The problem is when they arrive on a sub-page of the website and the store has not been set previously by the user. This also impacts SEO.
Question: How do I set the default store, without affecting the lightbox that is appearing on the home page.
From the comments traded back and forth, it sounds like your default store isn't set properly. If you aren't using any index.php hacks to do with store view setting, you should be able to follow the following steps to resolve this:
Magento: Setting the default homepage / store when you have multiple stores
When I add a product to my cart, I get the "empty cart" page.
I run Magento 1.7.0.2.
I have a writable session dir (var/session/) and see sess_* files being created
I have the following cookie settings (System -> Configuration -> Web -> Session Cookie Management): Cookie Lifetime = 10800 (3 hours), Cookie Path = empty, Cookie Domain = empty, Use HTTP Only = Yes, Cookie Restriction Mode = No
I already tried: Use HTTP Only = No
The cart/checkout is set to go trough HTTPS, but I have the same base URL's for secure and unsecure. I tested this (HTTPS front end Yes and No) and it makes no difference...
I checked the addAction() on the Mage_Checkout_CartController and it gets the params and adds the product + saves the cart
I checked the chooseTemplate() method on Mage_Checkout_Block_Cart and this gets a cart's items count of NULL, when I manually/ (hard code) change this to 1, then the cart 'filled' template gets rendered (also rendered correctly, but 'of course' no items)
I cleared cache and session data in between testing and trying...
Anyone had this and fixed this somehow? Or any suggestions on what to try next?
The following solutions worked for us. This is a late answer and I still consider to post an answer to this question so that it may help other people who are still stuck and looking for more solutions to try.
First we switched our domain to www which caused this problem. We fixed that problem by removing the caches, sessions and cookies. But we started experiencing that problem again and we thought that it was complex situation for us since we changed some javascript, www and SSL. But finally we found out that some products had 0 quantity and we were unable to add to cart. The cart page was hiding the out of stock message as error since it was ajax cart page through another module and theme. Then We set correct quantities for those items and the empty cart page is gone.
I'm on Magento 1.4.1 and get regular calls (2-3 per week) from customers that they are unable to add products to their cart. The symptoms are the same for customers: All use IE (7 or 8, most commonly). When they attempt to add to cart, they are taken to an empty cart page. Repeated attempts do not resolve the issue. I have not been able to verify, and the only version of IE I have access to is 9. I would dismiss this as user error except for:
Generally lower-than expected conversion rate on my site (explainable if large % of IE customers are unable to transact).
Consistency of symptoms: Browser and version, action that is failing
I assume this is an issue with setting the session or cookie (but could totally be wrong and am open to other suggested causes). If it is a cookie issue, I've found this post and this post from Stack Overflow which give a little information, but not a solid idea of how to go about confirming it is a cookie or session issue.
Can someone suggest the best way to get started with diagnosis?
setting cookie lifetime to 86400 as recomended here did the trick for me.
IE9 bundles development tools (from settings menu) and this allow you to emulate ie7 - ie9 versions in all compatibility modes.
If you are getting blank pages then there is always a php error behind this and you can see those errors from your server php error log.
We had a similar issue with items disappearing from the cart, it only happened in a store that was using a subdirectory of the main domain, and only with ie9 and older ie's. We also had varnish running on the frontend, and magento 1.4.1.1
e.g.
www.example.com = main store
www.example.com/sub/ = secondary store
After adding items to the secondary store basket in ie9, you could then go to the main store and add more items, return to the basket page and all was well then if you went to another secondary store product and added another item to the basket, then visited the basket page all previous items had gone, but the one just added was there.
We found we could consistently reproduce this by visiting a secondary store product page, adding to the basket, visit the basket - item is there, return to the product page, return to the basket, item has gone. It turned out to be a bad background image url in the stylesheet, and the rule was only used by the product page template, this 404 error was enough to cause ie9 and older ie's to lose the session and start a new one.
ie10 and 11, chrome, firefox and safari didn't have this problem at all, so if you're getting intermittent customer reports of baskets suddenly being empty, check the whole site for 404's, all it can take is one missing image to lose the session for ie9 and older ie's.
When a user visits a page, does the system check if the user is loggedin on every page, with every link click or is this a one time thing? The issue I am having is: The user logsin which works fine. But if i enter the URL to my signup page the system directs me to the signup page and changes my header back to as if i am a non user. And this is happening randomly on many pages. Some places without signing in it is showing me the registered user's header. So i assume the session is not working but I am not sure how the system knows or checks this or if it is auto or do we need to write code for each page, each link on each page? Platform is codelignitor php.
Thanks.
I would think this depends on what language you are using for your pages. Some more details would be helpful here. The system may be using a cookie to check if you are still valid and this cookie is expiring.
I guess you are missing the session check codes. Please check the session set in every controller class so that if logged in session is not enable just redirect to general user page else to logged in user page.
Probably there are some controllers that are protected and some public. If you are using an Auth library probably there is a method like $this->auth->logged_in() or similar. Check it in the contrsuctor of each protected controller, or, better yet, make a protected_controller class that extends CI' base controller, that does the job. Then make protected controllers to use this as base.
I am not able to check if user is logged in or not in magento system. I need to check it in footer.phtml file and show the footer links accordingly. It is working in some of the pages but not in all pages. when i gone inside in the issue and printed session array it is not accessible in some pages and in other pages it is accessible.
I used below code to check if user is logged in the system or not.
Mage::getSingleton('customer/session')->isLoggedIn()
and
$this->helper('customer')->isLoggedIn()
But it return false in some pages but works in others.
and also when i gone inside the footer and printed the current action and module name.
it is showing module customer and action create where as address bar shows customer/somethingelse.
I am very surprised.
Please help.
Thanks.
Footers are cached blocks which exempts them from session data. You will need to either disable the HTML blocks cache completely or modify Mage_Page_Block_Html_Footer so it is not individually cached.