0

I have a Magento site I've acquired. It's been upgraded from 1.6.x to 1.9.0.1. There were a couple of issues related to the new form_key tag which were fairly easily resolved, however there's one persisting.

The site has two store fronts - their main http://[domain] store, and a second at http://international.[domain]. Both work perfectly for allowing orders to be placed/paid for/etc (after the fixes above).

I can log in to the main site at http://[domain]/customer/account/login/ no problems at all. Entering a valid username and password I get a POST to /customer/account/loginPost/, then a 302 redirect to /customer/account/, and I'm logged in.

If I try to log in at the international version with an incorrect password it correctly gives me an error message. If I log in with a correct password, it POSTs to /customer/account/loginPost/, then a 302 redirect to /customer/account/index/, then a second 302 redirect to /customer/account/login/. At this point I appear NOT to be logged in.

If I look in log_customer I can see the successful logins:

log_id  visitor_id  customer_id login_at            logout_at           store_id
1329    1059310     538         2015-01-26 02:03:09 2015-01-26 02:03:09 2
1328    1059300     537         2015-01-26 02:01:14                     1
1327    1059307     538         2015-01-26 01:53:38                     2
1326    1059300     537         2015-01-26 14:58:42 2015-01-26 01:58:42 1
1325    1059300     537         2015-01-26 14:47:43 2015-01-26 01:47:43 1
1324    1059303     538         2015-01-26 01:46:55                     2
1323    1059299     538         2015-01-26 01:43:04                     2
1322    1059300     537         2015-01-26 14:47:21 2015-01-26 01:47:21 1
1321    1059295     538         2015-01-26 01:39:48                     2
1320    1059289     538         2015-01-26 01:35:38                     2
1319    1059285     538         2015-01-26 01:32:26                     2
1318    1059275     538         2015-01-26 01:28:56                     2
1317    1059273     538         2015-01-26 01:11:06                     2
1316    1059270     538         2015-01-26 14:10:32 2015-01-26 01:10:32 2

Store 2 is the international one (with the issues), store 1 is the main (fine) one.

One thing leaps out at me here - the very first attempt today had me logging in at 14:10 (which is the correct local time), then logging out at 01:10 (which is the GMT time). All subsequent attempts have the login_at timestamp set to GMT.

There's also something weird with cookies which I can't quite reproduce. On my first attempt I could log in no problems. After deleting all my cookies I could not. Weirdness.

edit: Found something interesting immediately after posting. There are several cookies, but notably two called frontend. One has the domain set at .[domain], the other .international.[domain]. Both had the same value. I deleted the former, and could now log in/out/in again no problems. Visiting the main [domain] site broke this again.

What appears to be happening is that the top-level cookie is overriding the international. version. The session is then invalid (or at least broken), because the domain/store is wrong.

I'm pretty sure if I change the main storefront to be www.[domain] that it'll fix the issue, but for vanity reasons we'd prefer to keep as is. Can I make the cookie stay within the main domain and NOT subdomains?

A possible red herring (or just an unrelated misconfiguration) - after deleting the cookie, the entries in the log_customer table are timestamped with LOCAL time, not GMT time.

edit 2: I tried forcing the cookie domain in configuration to .[domain]. This allowed me to log into the international version... but broke the main version. Definitely feels like this is the right track, just stumped as to how to actually resolve it.

1 Answer 1

2

Discovered my own solution.

Some third-party code to handle the multi-site implementation was causing issues. What was happening was it was doing a cross-site request to let the main site know to forward users back to the international site. This request was in turn starting a session on the main site, overriding the international one.

The code was evidently created with sites on distinct domains in mind (i.e. for separate country versions), and just had the side effect of severely limiting functionality with the sub-domain configuration.

3
  • Nice clarification. Thanks for posting the solution Jan 26, 2015 at 20:52
  • Is this a common third party module that we can look out for?
    – Tyler V.
    Sep 15, 2015 at 20:41
  • Third party written by another development firm for our customer, so hopefully not something you'll come across :)
    – SpoonNZ
    Sep 21, 2015 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.