Guest views

Sorry to be direct but have you actually upgraded to version 4.1.8 . This was a an issue with 4.1.7 which was updated within an hour or so to 4.1.8

Make sure you have the 4.1.8 file Login.php . To be sure

Open includes/classes/kernel/Login.php and check the _init function is like this:

Code:
function _init()
{
if ( ! empty($_SESSION['logged'])) {
if (!$this->_checkSession()) {
$this->_logout();
}
} elseif ( ! empty($_COOKIE[$this->_cookieName])) {
if (!$this->_checkRemembered($_COOKIE[$this->_cookieName])) {
if ($this->msg == 'Invalid cookie') {
$this->_logout();
}
}
} else {
$this->session_defaults();
}
}

If you have your user groups set to all show the same fields, then why would it matter if there is a cookie set or not? Logged in or not, registered user or not IF all user groups are set to display the same exact fields then it shouldnt matter what user group the forum thinks you belong to the fields should still be displayed. This is why I think there is something else going on.

have you all done the obvious - clear browser cache and cookies. Clear the templates_c folder as well.

Please post links to your sites rather than screenshots - some of the urls do not even come at all unless I am mistyping.

Not my logic. This is part of the Login file distributed with 4.1.8 if I am not incorrect.

What I can tell you is if you are not logged in I see no issue in firefox or safari. However , it is clear you changed the template but you may not have introduced prior changes to your template. That is why you must test on the default template first.

So in firefox and safari I logged in and had no problems with the showlistings. When i logged out - you have changed the code I did get a white screen. Nonetheless, the showlistings will display again.

It is a strange problem because I do not have any issues on 24 templates across 3 different systems.

Works fine for me. Logged in. Immediately quitted without logging out. Fired up the browser again and no issues except it kept me logged in which I always think is a bad idea in general. I have the browsers set to always accept cookies.

login as user user here

My Classifieds Website

What happens for you.

Please be clear Nick.

Are you on a 4.0.9 system or 4.1.8?

On our demo site at least , I get this behavior (cookies allowed)

1. If I login and logout normally then I have to log in again whatever I do.
2. If I log in and then just kill the window but not the Firefox application itself then it keeps me logged in.
3. If I log in and then kill the Firefox application then it is necessary to login again.
4. If I login in, click the remember me checkbox and then kill the application it is necessary to login.
5. If I login in, click the remember me checkbox and then logout normally it is necessary to login.

Is that what you are getting on our demo and on your system - where is the difference?

On Nzyan's site and on our test sites using the default template, I get the same behavior but no other problems. It looks like the remember me check box is not working as it should. It also looks like when you kill the application it does not remember a cookie because in our system when you have set a template in our template switcher it should be remembering the last template selected.

This is strange as the behavior with Safari is not the same as with Firefox. I do not think this is template related as the same behavior is present with the default as you have said.

3. If I log in and then kill the Safari application then it is not necessary to login again. In Firefox it is necessary to login. I see no difference in how the browsers are set up either.

What does number 3. do in I.E 7 and 8?


What does differ is with TemplateCodes deployed is we don't get the problem of listings getting screwed up. This indicates to me that one of framework module is partially correcting the issue that you have but not all of the issue (i.e the remember me checked in is not behaving as expected).

I just took a look at a 4.09 site which has no Templatecodes modules or anything else. A clean system in effect.

3. Both in Firefox and in Safari, it is necessary to login after killing the application (both FF and Safari).

but it is still necessary to login even if the checkbox to remember ID is clicked.

Now I am getting confused.

Lenny Kravitz springs to mind?

Now I just did a virgin install of 68C on a test domain. I get identical behavior to our demo system.

This is suggesting that something is either happening on the server side or in the core files. It is not template related. One thing I have noticed is that my web host has recently installed a new version of php and perhaps the php.ini settings are slightly different. It seems difficult to get to the bottom of this issue.

create a directory on your own server space and set your session.save_path to point at the new folder on your own disk space and I bet things will work much differently.

My guess is that you guys are relying on the web servers default session.save_path variable and its too small to accomidate the number os sessions its asked to store so they are getting cleaned out and therefor not available when you open the browser and go back to the site.

The way its designed you should only have the possibility of 3 values for msg, '' i.e. message never set, 'Invalid cookie' - meaning parts are missing from cookie i.e. manipulated by user or the hash and username do not match what his stored in the database, or 'User banned'

The method _checkRemembered only returns false when a message is set, and it will either be 'Invalid cookie' or 'User banned'. Banned members are not logged out as to keep them limited to banned permissions, otherwise it should be 'Invalid cookie' which should then log them out and destroy the session and cookie, and redirect to the login form.

So the initialization process works like this:

If they are logged in, check their session, if its not valid log them out, ie destroy session + cookie and redirect to login. If they are logged in and have a valid session do nothing.

Else If they are not logged in check the cookie, if its valid and they are banned or valid user do nothing

Else if they are not logged in via session or the cookie is not set, make a default session.