Can't login - "Cookie has not been set" - *Solution*

ridgerunner · 2010-03-15 17:00:00

Have you discovered that, just recently, you can no longer login to a FluxBB 1.4 forum? You get the brief: "Logged in successfully. Redirecting..." message, but then you find that you are NOT actually logged in? Or have you discovered that you can no longer login to a FluxBB/PunBB 1.3 forum (such as this very one!) and you now get the following message?:

Forum message wrote:

"You appear to have logged in successfully, however a cookie has not been set. Please check your settings and if applicable, enable cookies for this website."

Did you check to make sure that cookies were enabled and found that they were already enabled? Is this frustrating to you? This is what I experienced a year ago and after a bit of research, found a solution. I posted details about this issue over on the PunBB forum, but since this problem also affects FluxBB 1.4, I am updating and re-posting that information here.

Symptoms/Prerequisites: - You live in the USA or Canada. You are running Windows XP SP2 or older. You do not have Windows Automatic Updates turned on and have not installed all the Windows update patches. You manually set the clock forward one hour (to the correct local time) since the new Daylight Savings Time date: March 14, 2010.

User workaround 1: - select the "Log me in automatically each time I visit." checkbox when logging in. This gives a 2-week expiration for cookies which allows you to login with no problem.

User workaround 2: - Leave the Windows local time set one hour slow and let it automatically "Spring Forward" on its pre-programmed date: the 1st Sunday of April (Apr 4, 2010).

Administrator solution: - During the affected time period in March and April, forum administrators should set the "Visit Timeout" value to greater than 1 hour - say 1.5 hours = 5400 seconds (default is only 1800 seconds which is too small).

Description of the problem: - To make a long story short, the problem is related to Daylight Savings Time (DST) and Windows XP users living in locations (such as the USA) where the government has changed the date on which the time change occurs. In the USA the date to "Spring Forward" was changed from the 1st Sunday in April to the 2nd Sunday in March. (We are in this time period right now.) It turns out that Windows XP has a patch to fix this problem that is automatically installed if you have the "automatic updates" turned on. But if you (like me), do NOT have auto updates turned on, you may not have this patch installed. (You can read about this Y2K-like problem and get the DST patch here.)

The login problem only occurs when you (as a good time-keeping citizen) manually set the Windows clock to the correct local time when the time change occurs (the 2nd Sunday in March). The Windows clock becomes effectively one hour fast (with respect to UTC), and the FluxBB/PunBB cookie default "Visit Timeout" expiration time is set to be 1/2 hour (1800 seconds) into the future from the time of login. Thus, cookies are arriving at the browser pre-expired by 1/2 hour and login fails because the cookie is not set. (This behavior occurs with Internet Explorer (version 6 and 7) and Opera (9.x), but does not occur with Firefox (2 and 3))

After April 4, this problem should automatically disappear.

Here is some additional information from another post about this issue...

The cause of the problem is most definitely on the client end. In the affected areas (USA, Canada and others), a Windows (XP SP2 or earlier) box without the DST patch gets confused during this short period between the 2nd Sunday in March and the 1st Sunday in April. During this time period, if the local time is manually set correctly (ahead one hour), the internal GMT time (or UTC) is off by one hour into the future. So the Windows clock in the corner displays the right local time, but the internal universal UTC time (which is the time used by the browser when dealing with cookies), is one hour fast. The server is doing everything right. The PunBB forum software is just being too restrictive with the cookie timeout when dealing with computers that (unwittingly) have their clocks set 1 hour too fast. (Or more precisely, any computer that has their internal UTC clocks set "Visit timeout" seconds too fast.)

Note that this problem goes away after April 4 and the forum "Visit timeout" can be set back to 1800 seconds (or whatever) with no ill effect. However, the problem will continue to occur each year, from...

2010-03-14 thru 2010-04-04
2011-03-13 thru 2011-04-03
2012-03-11 thru 2012-04-01
2013-03-10 thru 2013-04-07
2014-03-09 thru 2014-04-06
2015-03-08 thru 2015-04-05

Hope this helps.

FSX · 2010-03-15 18:11:59

What about storing a timespamp in the cookie itself? And set the cookie expiration time + 2 (or more) hours.

ridgerunner · 2010-03-15 18:21:16

FSX wrote:

What about storing a timestamp in the cookie itself? And set the cookie expiration time + 2 (or more) hours.

That's exactly what the code does right now with the "Visit timeout" setting. The problem is that the default time is set to 1/2 hour and not 2 hours. Its easy to fix from the admin panel.

Last edited by ridgerunner (2010-03-15 18:21:34)

Mpok · 2010-03-16 01:30:19

Is this related to the "logout" problem in RC1 ?
(which occurs even in Linux)

Reines · 2010-03-16 08:26:48

Mpok wrote:

Is this related to the "logout" problem in RC1 ?
(which occurs even in Linux)

No, though that has been fixed now.

ridgerunner · 2011-04-01 17:34:01

Its that time of year again! BUMP!

Forums

#1 2010-03-15 17:00:00