Symphony.

In fact, they can. It just hasn't been implemented. Is this something more people would like? I am willing to implement this, and send a pull request.

After looking at the database, it seems the dates are in fact updated every time a page is viewed. Very strange.

edit: Ah, the database is indeed updated, but the actual cookie stored with the browser isn't. So, after two weeks (the default lifetime), the session is still up-to-date in the database, but the cookie is not sent any more.

This will create lots of unneeded entries in the database, as they will only be cleaned if they are more than 2 weeks old (so, two weeks after the last cookie has been sent, which is 4 weeks if you are a regular visitor).

So, long story short, we should either:

• Set the cookie to never expire, and delete manually if no record is found in the database (indicating the session has expired).
• Update the cookie itself to its new expiration date every time the database is updated
• Stop updating the timestamp in the database.

Now, the first two solutions will also fix the issue with being logged out after two weeks, and also clean up the sessions table. The third solution will only create a cleaner database. Which do you prefer?

@creativedutchmen: I think it's time that this gets fixed. I have installations with more than 177.000 rows in the _sym_sessions table, which can not be explained with the number of visits.

Concerning the behaviour: I personally don't really like users remaining logged in. Users like it, but I don't. From a security point of view, it's bad. We should check some of the major web apps (like Amazon) and see what they do. I am willing to follow a "common sense", of course.

michael, I think the best behavior is opt-in. A "remember me" checkbox should do. And, IMO, that can be solved a whole lot easier with a standard cookie than with a modified session handler.

Came across this very interesting read.

My proposal would be the following: implement the schema described in the interesting read, with an additional timeout of two weeks on both the cookie and the database row.

Normal visitors would be given a regular session, which is far more reliable than what we have now.

hey guys,

apart from the general discussion about the pros/cons of having sessions written to the db, i still have the problem of getting logged out from the backend when refreshing the frontend. it seems to be the language redirect extension which is causing this behavior on my live setup (development setup works fine). my regex/htaccess -fu is kinda low so maybe someone can help me out here.

this is the redirect rule (default extension rule)

RewriteCond %{REQUESTFILENAME} !-d
RewriteCond %{REQUESTFILENAME} !-f
RewriteRule ^()-?()?/(.*/?)$ index.php?language=$1&region=$2&symphony-page=$3&%{QUERY_STRING} [L]

back to sessions: can someone explain to me why i have not one single entry in my sessions table? when and where is such an entry to be written?

thanks guys,
daniel

For everyone in this thread:

• PHP Version
• What's your server and how is it configured? (ie. Apache/FastCGI etc.)
• Do you have Language Redirect or Members installed?
• What is the value of $_SERVER['HTTP_HOST']
• What is the value of the Symphony constant URL

In the past, issues with constant redirect loops have usually been something to do with the the Session->getDomain() function failing to actually resolve a domain (ie. localhost or 127.0.0.1.

@michael-e, I believe this issue with lots of session rows is something to do with how Symphony, Members and Language Redirect interact with the $_COOKIE/$_SESSION variable. At the moment if Symphony clears it's index, the $_SESSION will not be deleted because Members/Language Redirect are holding it open. I have a fix locally that should resolve this issue, but first I'm interested in what configurations users are using.

In the future Session handling will probably become decoupled from the core for better flexibility and support with cloud hosting providers, but in the meantime it would be nice to debug the situation and find out why things are acting up (in some situations)

Hi Brendo,

thanks for looking into this and trying to help! :)

My setup on the live system is the following:

• OS: Gentoo
• PHP: 5.2.14-pl0-gentoo
• Apache: 2.2.16
• MySQL: 5.0.54

The output from $_SERVER['HTTP_HOST'] and Symphonys URL is identical except that the symphony constant prepends the protocol (http://).

I have Language Redirect installed and my logout issues disappear when i remove the event from the pages. but you can imagine how this is not an option ;)

here is what happens to $_COOKIE and $_SESSION while language redirect is enabled:

upon login:
http://pastie.org/4044789

going to the frontend:
http://pastie.org/4044793

making another click anywhere on the site:
http://pastie.org/4044798

so the login credentials get erased from the cookie and session. not once does anything get written to sym_sessions.

cheers
daniel-

I’m seeing the exact same behavior that Giel described on a site recently updated form 2.2.5 to 2.6.1. Any insights into what causes this? Is this some leftover from the 2.2 version?

Hmn, well the behavior turned to normal after a while. Strange!

IMHO, after updating from an old version, deleting all the sessions can help.

@michael ok thanks, will try that next time!