Anyone?
This is really urgent. If there’s anyone who can help with an hour or two of their time, I’m happy to pay. I just really need to get this sorted out and I’d prefer the help of someone who is already familiar with MODx to know how everything interacts.
Dimmy, isn’t this for the CMS session and not the web user session? I’m stuck trying to find this line for web users...
-
☆ A M B ☆
- 24,524 Posts
It all uses the same SESSION, which session_name is stored in the cookie. It’s initially set in the function at the end of the config.inc.php file. All logging in/logging out does is add to the SESSION or (in the case of WebLogin) clear the SESSION on logout (which is something that needs work; it should only remove the WebLogin relevant array elements, not clear the whole session).
When I tried that, the login screen would no longer let me log in! Switched it back to the text and the login worked once more.
Could it be because the session.cookie_lifetime is set in my php.ini files elsewhere? I can’t think of any other reason why it wouldn’t work.
Anyway, the problem still seems to be related to the session files disappearing from the directory. I guess that’s not a MODx-related problem if it is some sort of garbage collection, but I don’t understand how garbage collection is happening when I have no cron jobs set up for it. There’s definitely a shortage of session files going on.
Stranger still, in the past 15 minutes, about eight empty sessions have been added to the directory - three all in the same minute, then four from the same minute that a manager user logged on, one two minutes later.
ARGH! So, I extended the time to a week for the session.cookie_lifetime in all my php.ini files. Seemed to work a treat for the first day and a bit. However, I logged in as a web user about three hours ago and it’s logged me out. If my cookie is valid for a week, why, when I do a grep on the temp session directory, has the cookie been deleted????
I’m going to try setting garbage collection to 1/1000 chance of starting out of desperation.
Anyone? I’m going to lose my job if I can’t figure this out soon. I am seriously willing to pay for someone to have a look at this.
Latest discovery is that after deleting all the browser cookies and logging in again, the site generates five cookies and each has a different expiry (listed in this order):
_utmb - expires 24 mins from login (valid for .mydomain.com - no ’www’), contains 180808114.1.10.1283514511
_ubmc - expires end of session (valid for .mydomain.com - no ’www’), contains 180808114
_utma - expires 2yrs from now (valid for .mydomain.com - no ’www’), contains 180808114.1010225969.1283514511.1283514511.1283514511.1
_utmz - expires 6mths and 2 days from now (valid for .mydomain.com - no ’www’), contains 180808114.1283514511.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
SN4bfd6fdda0a7a - expiry is blank blank (valid for www.mydomain.com), contains f2oshifd12mv6puvaffgd5sms1
Any ideas? I’ve got the php.ini file in as many directories as I believe it’s required, including the directories for weblogin, EasyEvents and TinyMCE.
Can nobody shed any light? I’m finding things out bit-by-bit, but I’m really no closer to a solution. Even the offer of money hasn’t helped!
I’ve discovered that those utm* cookies are created by google analytics. This means that only the last cookie is actually being created. It doesn’t time out on Firefox for a few days, but it still times out really quickly in Safari (and probably IE too).
How can this be?
@Chocoholic My php.ini:
; 3 days login
session.cookie_lifetime=259200
session.gc_maxlifetime=259200
Haven’t tested it for 3 days yet but restarted Rockmelt and
I’m still logged in and have been longer than I used to be before.
update
3 days - [CHECK]
Thanks mate. I solved it a few months back. It turned out to be a typo in the javascript. Line-by-line checking found it in the end. The login now works perfectly.