Login redirecting to different subdomain (www vs no www)
I have Sendy installed at http://www.mydomain.com/sandy/ (not my real domain). When I login, I see a redirection to http://mydomain.com/sandy/ which then redirects me back to http://www.mydomain.com/sandy/login, prompting me to login again. This cycle will repeat indefinitely.
After the first login attempt, manually entering the URL http://www.mydomain.com/sandy/ will get me to the main dashboard screen, correctly logged in. Thereafter, everything works fine. I presume this is because my license file is showing as registered to mydomain.com rather than www.mydomain.com.
(I see the same behaviour if I login using http://mydomain.com/sandy/login.)
I've checked my .htaccess rules and can't see anything that would rewrite the base URL to include a www prefix, so I guess this is being done by Sandy itself? Do I just need a new license key that includes the www prefix, or is there a more straight forward fix I can apply, to avoid this two-step login?
Comments
Hi Eddy,
I checked your phpinfo and saw that your PHP's
session.save_pathis not set. As a result, Sendy is unable to write session data. That is why you are not able to login.Please contact your host to set this.
Thanks.
Ben
Thanks Ben. I went ahead and set session.save_path in my site .htaccess; the setting seems correct since I can now see sess_xxxxxx files being created in the session path folder in response to my login attempts.
However, the login sequence is still behaving as originally described (I re-checked from a fresh PC to make sure it wasn't some sort of cache issue).
I used Wireshark to record the exact login sequence. The full trace is at http://mydomain.com/sendytrace.txt, but in brief:
(client)
POST /sandy/includes/login/main.php HTTP/1.1
Host: www.mydomain.com
(server)
HTTP/1.1 302 Found
Location: http://www.mydomain.com/sandy
(client)
GET /sandy HTTP/1.1
Host: www.mydomain.com
(server)
HTTP/1.1 301 Moved Permanently
Location: http://mydomain.com/sandy/
(client)
GET /sandy/ HTTP/1.1
Host: mydomain.com
(server)
HTTP/1.1 200 OK
Javascript: window.location = "http://www.mydomain.com/sandy/login"
(client)
GET /sandy/login HTTP/1.1
Host: www.mydomain.com
(server)
HTTP/1.1 200 OK
(normal login page redrawn)
I can also see the logged_in cookie being passed back & forth during the sessions with www.mydomain.com (though not mydomain.com, of course).
Any other thoughts?
Eddy
(Apologies for the sloppy formatting above; I swear it was nicely formatted when I hit the 'post comment' button!)
Hi Eddy,
I suspect there is a spelling mistake in your
session.save_pathvalue. 'limelight' seems to be misspelled as 'limeligh'. Is that correct?Ben
Hi Ben,
No, 'limeligh' is correct -- the hosting service only allows up to 8 chars for the account name; as I mentioned, I can now see session files being created in the session folder, timestamped to match when I attempt to login to Sendy.
Eddy
Hi Eddy,
If your session path is set correctly and you still couldn't login in, could it be your email and password combination is wrong? Have you tried forget password to reset your password? *Note that your login email needs to be verified in your SES console in order to receive your "forgot password" email.
Thanks.
Ben
Hi Ben,
After some more trouble-shooting this end, I think the problem is down to my service provider's Apache configuration -- it is redirecting all references to http://www.mydomain.com/directoryname to http://mydomain.com/directoryname/ (with trailing slash, but no leading 'www' on the domain name). This happens for all directories on my site, not just Sendy. It seems to happen before the rules in .htaccess get scanned, so I can't rewrite it there. The 'logged_in' cookie doesn't transfer across the domain switch, which is why I am getting redirected back to the main Sendy login page each time.
I have a similarly configured website with another provider, and the redirection works as expected (preserves the original domain name), so I'm guessing it's a difference in Apache's global configuration. I've opened a ticket with my provider.
I expect the misconfigured session_path would have caused me problems anyway, so thank you for your help getting that resolved! In the meantime, perhaps a future release of Sendy could redirect successful logins to APP_PATH + "/" instead of just APP_PATH (as defined in config.php) which would avoid the problem completely and shouldn't cause any issues for existing customers. I fixed it locally (line 45 of includes/login/main.php) and now everything is working fine for me.
Eddy
Hi Eddy,
It sounds like the redirection from "www" to "non www" URLs is done in the vhost container on Apache in which only your host may be able to remove it for you. This should fix your issue so that you can login to Sendy just like everyone else without having to add a slash in includes/login/main.php.
Thanks.
Ben
Hi Ben,
I'd compared the virtualhost entries for my Sandy site and the other site I mentioned hosted with a different provider, and they had looked almost identical. Both of them used a ServerName of mydomain.com (no www), but the other site handled redirections properly, without changing the domain name.
After a little more digging, I discovered that my Sandy site has the Apache global setting UseCanonicalName On configured, while the other site has UseCanonicalName Off. With UseCanonicalName on, redirects always use the official ServerName; when it's off, they use the host-name provided by the client in the original web request.
So, mystery solved. Since it's a shared site, however, I doubt my provider will be changing it :-(. Both sites use HSphere for website management, and HSphere doesn't provide any way to change the ServerName to include a leading 'w
Thanks,
Eddy
Hi Eddy,
In that case, have you tried using a "non www" URL for
APP_PATHin /includes/config.php?Thanks.
Ben
Hi Ben,
Just tried that now and -- it works fine! So I've rolled out the change I made to login/main.php.
(I think I originally tried this early on, but the issue with the PHP session path prevented it from fixing things at that time.)
Thanks again,
Eddy