admin login opens up other instances' admin areas {0.12b1}

[kermit]

ok folks, try this at home:

set up multiple instances of cmsms on the same server. for me, paths are something like this:

wwwroot/testing/11cmsms  (0.11.2 install)
wwwroot/testing/cmsms      (0.12b1 install)
wwwroot/testing/cmsms2    (0.12b1 install with a later svn applied)
wwwroot/testing/cms-daily    (some 0.12-flavoured daily for awhile ago)

and they're all accessible at http://192.168.99.100/testing/(dirname) and they don't all use the same database. admin password is not the same across all of them either (it's username, 'admin', is the same on all four, though).

log into one of the admin areas. then change the path in the browser address bar to point to another instance's administration area and load it up instead. you get in.

ok. go to each one's admin area and ensure you're logged out (that the login page comes up). then try it again. login to one of them and then manually type in the url for another's admin area. you get in.

you can even hop from one version to another, whether the passwords are the same or not doesn't matter either.

this is on my breezy box running apache2/php4. haven't looked at this on my windows system yet but iirc, it occurs there too i, just never paid any attention to it before (kinda handy for testing actually, just not for the real world).

does not work across domains on a different server, dunno about different domains on the same server though.

just a guess, but it appears that the admin cookies are only recording & checking domain and not the site's complete url? 

[Ted]

Cookies generally work on a domain.  I believe a path can be worked in as well.  Though, it seriously makes me think that I need to look at this logic and see what I can to make this a little more tighter.

What it's really coming down to is that the same session is working on all 4 installs.  If the session times out, it will do a password hash match.

My best guess is that the admin url should be put into the session.  If it doesn't match, then it'll at least do the password hash check again.  That would help a little bit, though all nstalls with the same username/password will still have the same problem.

Quite a pickle...

[kermit]

well, i took a peek at my cookie culler extension for firefox.. the 'path' is associated with the cmsms cookies it says.. unlike most other ones which just list / for a 'path' (a 'domain' cookie?). of the ones sitting in my firefox at present, digg.com and google.com (corporate info areas) cookies also refer to a path. you should be able to specify the path of the cookie you want when requesting it?

i suppose you could come up with a 'site name' or a hash (perhaps generate one on initial install and record it? a few other cms use something like that for 'something') to insert into the cookie's name or content fields to ensure you're writing/checking the correct cookie for a particular installation.

i dunno. cookie manipulation is beyond me.. i just delete 'em every week or so, keeping the important ones, like my slashdot login and tv.yahoo.com/grid 

[kermit]

another tidbit of information:

i go to 192.168.99.100/testing/11cmsms/admin/

and login incorrectly.

i then immediately go to 192.168.99.100/testing/cmsms/admin/

and login properly.

the next thing that comes up is the admin panel, of course, but not for 'cmsms' but for '11cmsms'.