[Solved] Unable to login to manager after upgrading from beta 4 to beta 5

Upgraded to BETA 5, everything went ok.
But now cannot login to the manager.
Deleted the 3 session settings in mysql, cleared modx_session table. cleared browser cache, all to no avail.
Tried with FF 3.5.5 and Safari 4.0.4.
I’m testing on a server, not on localhost.
Apache-2.2.14, php 5.2.11, mysql 5.0.84.

What should I check next/how do I fix this?
And should I file a bugreport on Jira?

Seems the session settings were still in the modx cache file. Problem fixed after removing the file "core/cache/config.cache.php".

Deleted the 3 session settings in mysql, cleared modx_session table. cleared browser cache, all to no avail.

Maybe white space or an UTF-8 "BOM" in files you edited!?

Quote from: mrhaw at Dec 15, 2009, 06:21 PM

Deleted the 3 session settings in mysql, cleared modx_session table. cleared browser cache, all to no avail.

Maybe white space or an UTF-8 "BOM" in files you edited!?

No, this is related to changes made to session management between beta-4 and beta-5. If upgrading from an earlier version of Revo, you need to remove (or set a valid domain value for) the session_cookie_domain setting because localhost is no longer a valid session_cookie_domain and that is what previous versions set by default.

Aha!

because localhost is no longer a valid session_cookie_domain

Just a question but why is this? Do we need to set it like this ’localhost.localdomain’ i.e as per the hosts file, is this a PHP thing or something?

If you are using Konqueror it doesn’t care and will let you log in.
If you are using Firefox or something else and just can’t get it to let you in to change the setting you can do it in the database via PhpMyadmin by going to the Revolution database and selecting the modx_system_settings table and editing the session_cookie_domain row. a simple domainname.tld will work.

I wonder if everyone (or multiple sites) used localhost as the cookie domain -- how hard it would be to pull other site’s cookies and implement cross site hacks, etc. This should be changed anyway -- on all production servers, sites, and scripts referencing a cookie domain.

If you are running local you can always add a host name to your /etc/resolv.conf or hosts file or whatever your OS uses and point it to 127.0.0.2 or whatever leave 127.0.0.1 alone for localhost. Everything 127.x.x.x is considered localhost (loopback) http://tools.ietf.org/html/rfc3330

Yes, get you but ’localhost’ is a host name, not a domain name, the domain name from my /etc/hosts file is ’localdomain’, so we have localhost.localdomain to identify localhost by domain, the session_cookie_domain, if it is a domain, should have been ’localdomain’, not localhost. Also as you point out this should be picked up from your hosts file, not really set explicitly.

My only question here is to why this has changed now, it seems to be since the change to PHP5xx , however it doesn’t matter that much, It works, if we don’t need it anymore then fine, I was just curious as to why we did in the first place.

Shamblett,

I alluded to one security aspect of it above. If multiple people have the same name attached then a website can have access to all of the cookies on your computer with that name when it accesses its own with the same name. $_SESSION information can then be sent to the other site and "log" you in without your being there, if the cookie also has the url attached.

I could have been a little clearer in my previous post, but deliberately didn’t. Those of us who run a local dns server would be using the resolv.conf to point to it. In bind (or what ever you are using) you would include an entry to the localhost webserver. If you name the network .lan or .home or .yourname or .whatever you could then have a revo.lan as a name (or whatever you want).

The /etc/hosts file is the place for local resolution, but in some distros this file is overwritten on a network restart or system startup.

I did not go into more detail because I believe it is out of the context of this topic and even this forum to digress to much into the setting up or or the various considerations of these systems.

As most people run modX content on webservers with fully qualified domains this is a non-issue, though I believe the installer may need to be patched to pull the actual domain and insert it automatically into the table, as firefox and other browsers require two dots in the domain name to accept the cookie.

If people really want to play, they can get a dynamic dns address pointed to your router and redirect ports 80 and 443 to their local server. In their /etc/hosts file they can simply take the dyndns domain and point it to the local ip address, or even better setup the local name server to redirect that dyndns name to the local network ip and automatically publish that name to the local network when they access that dhcp system -- which of course is feeding off the localized dns server as the authenticated master.

To directly answer your question:
http://us2.php.net/function.setcookie PHP.net. This is a very old issue -- PHP 4+ is directly mentioned in the article, though I found IIS forums from 2002 also discussing this.

I hope this finally answers your question.