For months I had the problem that on and off I could not log into the develop branch. When it finally seemed a permanent problem, I pestered Sven until we noticed that develop tries to save a third-party cookie which my browser disallowed quietly, and so logins failed. Note that this does not occur on twiki.org.

I fixed my firewall settings to allow develop.twiki.org to sneak through the firewall, but I am still experiencing this problem when traveling. At some hotels or public sites I can log into develop, at others I cannot. Maybe I am the only one traveling, so it might not be a big problem, but there is something wrong with a system that requires saving of a cookie that many ISP do not allow. There is nothing the user can do in those cases to work around it.

I would suggest that we get rid of this cookie or, at least, warn the users in the broadcast message that when they experience login problems, this might be the reason.

For those who are curious, here is what this cookie is (the name is loginname @Bugs[ sequencenr ].txt ):

TWIKIPREF

develop.twiki.org/~develop/cgi-bin/view/Bugs/
1088
4219108608
29877052
2202517408
29803627
*

---

It appears to be coming from pub/TWiki/TWikiJavascripts/twiki.js, and AFAICT is used for per-session preferences such as the optional show/hide attachments switch.

CC

---

I find it strange that ISPs should be blocking cookies. I have never experienced that. It sounds more like it is a browser cookie. Thomas described the cookie as "third party" somewhere. It is not a third party cookie. It is a cookie coming from the same webserver that serves the web pages. _ Well, when I enabled "third-party cookies" it worked -- TW_

Did you use ~develop or ~twiki4 version of Bugs? I recommend forgetting the ~develop version. I get javascript errors when using ~develop and the hide/show attachment twisty is all screwed up. It has been like this for months and it seems the DEVELOP branch is no longer maintained when it comes to PatternSkin which is probably one reason why many of us agree to simply kill DEVELOP. I do not see any difference between the ~develop and ~twiki4 version of the bugs web -- TW

Does the domain name of the cookie match the domain name of the actual bugs?

KJL

---

I cannot see how setting user cookies for twisties can block access to a site. The above TWIKIPREF cookie content is not set by Pattern anywhere.

AC

Not pattern; twiki.js, where it is used for the show attachment preference.

CC

---

twiki.js only has the function. Skins and plugins can call that function. So yes, pattern (through Twisty) stores a cookie preference for the attachment table twisty. But it doesn't look like the cookie above.

Actually I don't believe cookies are being set now because of a bug on DEVELOP that causes the javascript to bark (that's why the twisties don't work either). Pattern skin hasn't been updated for ages here.

AC

---

In the meantime the problem has worsened. Since I updated my windows installation, I cannot log into the bugs web from anywhere. See a summary of the current situation:

• I cannot log into the bugs web. Symptom: When going to the log in screen and entering user name and password, the screen just returns blank in the same state (when coming to this screen after clicking edit) or just returns to the previous topic (when clicking on the "login" link).
• After a lot of back and forth, Sven and I have traced this to that my firewall (Zone Alarm) had by default a setting which prevented "third-party cookies" to be written to my disk. After allowing third-party cookies (whatever that is, have no idea) to come through, I was again able to log in. The cookie that is written is posted on the bug web.
• But then I discovered that from some ISP (when traveling in hotels) and also from public computers, such as those in the Admiralsclub lounge (where cookies are not allowed to be written) I could not log in.
• That was only a minor nuisance until after upgrading to Win XP SP2. Now I cannot log in again. Even when disabling my firewall (I do not use the Win built-in firewall) this problem persists. I have enabled all cookies on my browser, and added develop.twiki.org to my local site list on the browser, but the problem still exists. My disk has ample space to write. Even when turning all security settings I cannot log in.
• There are no such problems on twiki.org.

---

From an email by CC:

The reason you can't log in is that bugs web uses Template login, which requires sessions to work. The sessions code caches the session ID in a cookie, which is then used to maintain the logged-in state. It's not just the TWIKIPREF cookie causing your problem. It can be reproduced by anyone who switches off cookies, starts a new browser and tries to modify a bugs topic.

---

But I did not switch off cookies. In fact, I have plenty of cookies from all kinds of sites on my drive. So there must be something unusual that twiki is doing in these situations that causes these difficulties. Why would doubleclick or chase or whatever have no difficulties writing cookies, but twiki does? In fact, there are currently 1069 cookies on my drive... This seems to tell me that whatever twiki does it sure is not right... -- TW

Note that the checkins below are unreleated to this bug but were used as place holders due to my inability to log in -- TW

---

Closing this; if you get any inspirations as to why you couldn't log in despite enabled cookies, please open a new report. Thx.

CC

Crawford, I fear that there is a problem with template based login. Shouldn't we look for what is wrong, rather than just using apache login and closing the issue? Please close again if you really think there is no problem... -- TW

I really, really don;t think there is a probem with Template login. I think there may be a problem with your environment, which can only be nailed down by you, unfortunately. But I'm sitting here behind multiple layers of firewalls, with cookies of and on in the browser, and all sorts of other jiggery-pokery going on, and Template login is just fine as long as cookies can get in.

Closing again, until someone produces a reproducable test case.

CC

Re-opened.

The HOST name of some of the cookies does not match the actual host. Probably some setting issue because it is only here on Bugs I see the problem. Not on my own test server.

The HOST in some of the cookies is "twiki.org" instead of "develop.twiki.org".

That makes the cookies 3rd party. I changed the AppliesTo to BugBase because it is the setup on this server that is the issue. Somewhere it says twiki.org where it should say develop.twiki.org.

I cannot see the configure script so I cannot say what and I do not have login account to bug either. I wonder why not since I am a core member.

KJL

Here's what I just tried:

1. Shut down all browsers
2. Restart a new browser. Delete all cookies with "twiki" anywhere in their host, name or value
3. Opened this topic
   • At this point I have one cookie with "twiki" anywhere in it; TWIKISID, host develop.twiki.org
4. Edited
   • Logged in using my user id
   • No change to cookies

i.e. d.t.o creates a single cookie, TWIKISID, with the host correctly set to develop.twiki.org, exactly as I would expect.

Of course twisties are not currently enabled (what happened to them?) so it may be a cookie from there that's the problem. But on the face of it, there's nothing wrong that I can see, so ping, closing this again.

You can't access configure because I locked it down while I was developing the configure changes. It's only accessible from certain IP addresses.

CC

Yes the PatternSkin / Twisty cookies are not working at the moment. And they are the ones that had the wrong HOST. TWIKISID has always had the right HOST. If some security software filters our pages with 3rd party cookies people like Thomas will have the problem here again when the PatternSkin works again.

You close the bug without knowing that the problem is fixed!

Re-opening. And it STAYS OPEN either till we have confirmed that the repaired PatternSkin no longer has third party cookie. If we leave it closed we will forget all about it.

KJL

Changed the headline and attribution to reflect that. Clearly if it's a problem on the bug base, it'll be a problem elsewhere as well.

CC

I don't think I understand this topic. Twisty cookies are set with javascript via the cookie scripts in twiki.js. All settings are set using TWIKIPREF - see TWiki:TWiki/TWikiSettingsCookie for documentation

Would it be necessary to include a path with the cookie? And which one (assuming that javascript has no knowledge of the cookie used in the Perl code)?

AC

Instead of guessing we should focus getting PatternSkin working without Javascript errors again and then return to this this bug report.

It is very likely that this issue will have resolved itself then. Can someone with admin access to develop.twiki.org please activate the plugins that the new PatternSkin needs so he skin can actually work.

KJL

They are not dis abled. AFAK TwistyContrib is the only piece needed, and it is installed. If you want to add TwistyPlugin as well, it needs to be added to MANIFEST first.

CC

I have updated MANIFEST. Let us see if this site picks it up.

AC

It does not. Someone (of the very few chosen) with the access rights to configure needs to click the checkmark for TWistyPlugin.

KJL

I enabled it and opened up configure again to stop the whingeing. I'm pretty sure it's secure enough with the password protection on.

CC

It works now.

AC

And all the cookies seems to come from develop.twiki.org now so I can confirm the closure. Thanks. Hopefully this should also mean that Thomas no longer has problems logging into Bugs when he is on the road.

KJL