Posting in the Magento forums has been disabled pending the implementation of a new and improved forum solution which should better serve the community.

For new questions please post at magento.stackexchange.com, the community-run support site for the Magento community. We will be providing updates on the new forum solution soon. For questions or concerns please email community@magento.com.

Magento Forum

Add to cart timeouts, redirects to index.php
 
phlux0r
Member
 
Avatar
Total Posts:  73
Joined:  2008-03-09
Auckland, New Zealand
 

Our client’s site is also experiencing intermittent loss of sessions as described here. We have just turned all the validation settings to No and will see if that helps.

However, what are the consequences of turning them all to NO? Is this a security risk?

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

All sessions are set to NO, RSS is OFF, yet I still have clients ringing up to state they are having problems.

i.e. the suggested fixes do NOT address this issue!

 
Magento Community Magento Community
Magento Community
Magento Community
 
PremierWeb
Jr. Member
 
Total Posts:  16
Joined:  2009-02-18
 

This issue is likely related to $_SESSION data and occurs in file app/code/core/Mage/Core/Model/Session/Abstract/Varien.php around line 325.  The bug occurs when the “Validate REMOTE_ADDR” setting is enabled and someone visits your site passing a X-FORWARDED-FOR header to Magento.

For whatever reason, the ip address defined in the $_SESSION array doesn’t correspond to $_SERVER[’REMOTE_ADDR’] and Magento kicks out an “invalid session” to the front page.

I’m perusing the code at the moment and hope to have a fix posted in the next few minutes.  For now, disable the “Validate REMOTE_ADDR” setting to allow proxy users (such as AOL) to checkout.

Note: This setting is intended to prevent session hijacking.  Disable at your own risk!

 
Magento Community Magento Community
Magento Community
Magento Community
 
PremierWeb
Jr. Member
 
Total Posts:  16
Joined:  2009-02-18
 

After digging deeper, this doesn’t seem to be an issue related to any flaw in Magento’s code.  User’s visiting your site sometimes surf on proxies.  Any non-secure pages are served from your site, to the proxy, then to the user.  Your server is going to initiate the session data based on the IP address of the proxy.  Secure pages however, by-pass the proxy server entirely and the user is requesting pages straight from your server.

The Magento settings “Validate REMOTE_ADDR”, etc are intended to prevent one user hijacking another’s cart/login session by putting ?SID=<session_id> in the browser.  To be successful, an attacker would have to know the session ID of another user currently surfing your site.  Magento’s security-check compares the user IP stored in the session and to the current surfer’s IP making the secure request.  Since the user visited your non-secure pages via a proxy, the session data contains the proxy’s IP address and it is being compared to the user’s (now-changed) IP address.  The comparison fails and Magento kicks the user out to the front page as an invalid session.

IP validation as a means of session security is not presently considered reliable, especially when dealing with proxies:
Session Security/Validation in a Proxy Environment

Recommended fix:

1. Disable all Session Validation Settings except for HTTP_USER_AGENT.  *Even this one, really isn’t necessary*
2.  If you’re concerned about users blind-guessing session id’s, you can increase your server’s session security by implementing the following in php.ini.

poll /dev/urandom or /dev/random for better session entropy (available on most Unix systems)
session.entropy_file = /dev/urandom
read 16 bytes from /dev/urandom
session
.entropy_length 16
;use SHA-as the session hash (usually MD5)
session.hash_function 1  
 
;session ids contain 6 bits0-9a-zA-Z"-"","
session.hash_bits_per_character 6

Mind you, these PHP ini changes decrease the likelihood of someone hijacking an active session id, which already is extremely difficult.  Your web server would likely crash due to the thousands of incoming page requests, before a session was guessed.  These changes probably aren’t necessary unless you’re getting a LOT of concurrent users (giving a hacker more valid session guesses).

Here are the .htaccess settings, which *should* work, depending on server configuration (we run Lighttpd so I can’t test)

php_value session.entropy_file  /dev/urandom
php_value session
.entropy_length 16
php_value session
.hash_function 1
php_value session
.hash_bits_per_character 6

Of minor concern is webpages indexed in search engines or cached copies of your site that contain session id’s in the URL.  Disable SERPs caching of your site if you’re absolutely paranoid, by adding the following to the top of your HTML pages:

<meta name="robots" content="index,follow,noarchive">
<
meta name="googlebot" content="noarchive">
 
Magento Community Magento Community
Magento Community
Magento Community
 
phlux0r
Member
 
Avatar
Total Posts:  73
Joined:  2008-03-09
Auckland, New Zealand
 

Thanks PremierWeb for shedding some light on this issue and the time you spent finding out what is happening. Your effort is much appreciated.

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

A customer has been complaining Google Checkout does not work with 1.2.1.2.  After discussing it with them - they claim they are being taken to the cart which is empty.  I am presuming this is part of this bug.  Not good, please sort this hideous bug out asap!  It has been ongoing for a long time and I have been and continue to lose many sales because of it.

all session validation has been disabled, and no, it has not helped one bit.

 
Magento Community Magento Community
Magento Community
Magento Community
 
DrBillNye
Sr. Member
 
Avatar
Total Posts:  96
Joined:  2009-02-07
Boulder, CO
 
MagentoJoe - 25 February 2009 09:02 PM

1. I’ve tested the latest Safari 4 browser the last few days and encountered a VERY strange default setting in it - Cookies were disabled! So, enabling this will also solve this kinds of problems. If Safari doesnt Enable it by default we’d need to write a little workaround and informing the Safari-customers to enable cookies (I dont think Varien will customize Magento to work without cookies)

I’ve run into something similar as well.  If someone has the cookies disabled, the items they try to add to their cart just disappear, and they are shown an empty cart.  This isn’t very intuitive.  I found a magento plugin that does a cookies / js enabled check, but it’s not a very pretty solution, ideally something akin to amazon’s would be best, where you can browse fine, but if you try to add to cart without cookies enabled it would notify you (we could put it right into the cart page I’d think)

Anyone know enough code to piece something like this together?

 
Magento Community Magento Community
Magento Community
Magento Community
 
pk1024
Jr. Member
 
Total Posts:  1
Joined:  2008-10-29
 

The problem is that some (bad) browsers have a bug where they can leave an additional space in the user agent for AJAX calls (that is not there for normal page loads from the same browser). This causes systems that compare the user agent (UA) strictly to fail, even though when a human looks at it - it seems to be the same.

Example:

123.123.123.123 - - [25/Mar/2009:12:54:26 -0500] "GET /checkout/onepage/ HTTP/1.1" 200 11219 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; MSN 9.0;MSN 9.1;MSN 9.6; MSNbQ002; MSNmen-us; MSNcOTH)"
123.123.123.123 - - [25/Mar/2009:12:55:18 -0500] "POST /checkout/onepage/saveBilling/ HTTP/1.1" 302 20 "https://store.intervarsity.org/checkout/onepage/" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727;  MSN 9.0;MSN 9.1;MSN 9.6; MSNbQ002; MSNmen-us; MSNcOTH)"
The first hit is a normal web request. the second is an AJAX call. Note the extra space before “MSN 9.0”

If you want to fix this - you either have to disable checking of the UA, or make the UA comparison smart enough that it doesn’t fail in that case. One option would be to search/replace double spaces in the UA before using it for comparison.

I know this is a rare bug, but I hope the Magento folks are listening and will take the time to clean this up. When it happens it is very difficult to reproduce and hence very expensive to debug.

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

great detective work, guys. let’s hope Varien are indeed paying attention!
this will be a must-have upgrade once this bug is resolved. progress updates from Varien on this thread are a must!

 
Magento Community Magento Community
Magento Community
Magento Community
 
ddeppner
Jr. Member
 
Total Posts:  23
Joined:  2008-08-10
 

I’ve done some independent work figuring out this bug and ran across this post.  I submitted a bug report and a link to this post in the bug report as further evidence.

This problem also affects SBCglobal/AT&T;/Yahoo DSL customers if they have a particular software set installed, in addition to the previously mentioned MSN users.

Bug report can be viewed here:

http://www.magentocommerce.com/bug-tracking/issue/?issue=5727

 
Magento Community Magento Community
Magento Community
Magento Community
 
DrBillNye
Sr. Member
 
Avatar
Total Posts:  96
Joined:  2009-02-07
Boulder, CO
 

did 1.3.0 help this at all?  Anyone try it yet?

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

Another client desperate to buy an item has been trying for about a week now..
the problem in his case is that the item is supposedly in his cart, he then goes on to click on ‘google checkout’, which then mysteriously states ‘oops, sorry, you have nothing in your cart to buy’!!!

he is using IE7/8 (on all 3 of his new machines he tried this on), and he is on orange and sky broadband (uk) - he has tried both suppliers.

 
Magento Community Magento Community
Magento Community
Magento Community
 
DrBillNye
Sr. Member
 
Avatar
Total Posts:  96
Joined:  2009-02-07
Boulder, CO
 

alex, I don’t know if this will work for you, but for me it was a cookies issue.  I had her turn her security setting to low in IE7 and I had turned off all the session validation settings and it worked. 

I was able to replicate what she was seeing when I turned up the settings on my IE so it wouldn’t accept cookies and that’s exactly what it did. 

Good luck,
Al

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

Told the customer to install FireFox and the order went through without any problems.

DrBillNye:  Told the client to sort his IE security settings out. wink

 
Magento Community Magento Community
Magento Community
Magento Community
 
alex.bsc
Guru
 
Total Posts:  340
Joined:  2008-06-06
 

Varien - there very much exists a problem with IE, possibly the security settings, probably due to the rejection of cookies.
Please incorporate a cookie check and inform users to sort their cookie settings out, if this is indeed the problem!

I have done all the session etc. adjustments in the back-end as suggested earlier.

There may also exist the proxy settings problem, more specifically the differing ip address between http:// and https://
The AJAX issue too could be a problem..

Lots of things to address really, but IE must work properly, as unfortunately 70%+ of visitors to my site use IE! This is a TOP SUPER-HIGH PRIORITY ISSUE!

 
Magento Community Magento Community
Magento Community
Magento Community
Magento Community
Magento Community
Back to top