Last modified: 2010-02-06 13:33:28 UTC
Session cookie is sent to the browser for non-logged-in users (IPs) only if user navigate through Special:UserLogin page. After that, even if the user doesn't log-in, the cookie is created and you can see the user's IP address in the top right of the page. I don't know if can be considered a bug, but I had some problems for that using some extensions that needed a session cookie, of exammple ConfirmEdit, an extension that use math operations to prevent editing by bots. I use that only for not-logged users... I patched my installation adding to my LocalSettings some code extracted from Special:UserLogin, from the execute() function. But a fix for the default installation of MediaWiki could be correct, I think. I think that could be useful to open session cookie for not logged-in users also. Thank you all -enrico ps: I found this first time with version 1.11.1, and then also with 1.12.0
Normally a session cookie will be created when going to the login page or when editing.
Yes, I omitted this. The session cookie is created also when you save the page edited. It is not created when you ask for editing a page, this is why I had problems with that extension.
ConfirmEdit indeed needs a session cookie, but doesn't make sure there is one. Perhaps it could call wfSetupSession() to ensure a session is present. Since ConfirmEdit usually triggers on a login or edit page, that would not be necessary - but it caused me some headaches when i tried to integrate ConfirmEdit with my ContactPage extension. So... IMHO, since ConfirmEdit requires a session, it should also set it up if neccessary. The same goes for other extensions: if it needs a session, it should call wfSetupSession().
I have just checked this with MediaWiki 1.16 and the latest version of ConfirmEdit extension. The problem no longer occurs with the cookie when anonymous users do edits.
(In reply to comment #4) > I have just checked this with MediaWiki 1.16 and the latest version of > ConfirmEdit extension. The problem no longer occurs with the cookie when > anonymous users do edits. Well, the edit page itself initialized the session, so it would never be an issue with editing anyway. The problem only arises if you want to use ConfirmEdit for some activity that does not of and by itself require a session.
