Topic on Project:Support desk

Hi,

I have a strange problem with my wiki installation. After a file upload the user is redirected to the file information page (e.g. index.php/File:example.png). However on this page, the user is suddenly logged out (unauthenticated), or actually appears to be logged out. In the top right corner the wiki displays the Log in link, instead of the username and log out link. When navigating to another page however, the user is logged in again (without actually having logged in himself). This problem is particullarly annoying for me, because I have a private wiki without read access for anonymous users (thus the wiki displays an unauthorized message). However, even when granting the read permission to anonymous user, there still is a problem, since the Wiki thinks you are not logged in and thus cannot perform any actions, such as deleting the file.

The versions I am running are: MediaWiki 1.22.0 PHP 5.3.10-1ubuntu3.14 (apache2handler) MySQL 5.1.73-0ubuntu0.10.04.1-log

I also tried to upgrade to the newest MediaWiki version (1.23.5), but unfortunately this did not solve the problem. I also tried a fresh install from scratch for this newest version, again with the same result.

Actually I am migrating my wiki from an old host to another host. On the old host this problem did not occur at all. On the new host it occurs immediately, even though the configuration for the MediaWiki is almost exactly the same. The versions for the old host were: MediaWiki 1.22.0 PHP 5.3.3-7+squeeze21 (apache2handler) MySQL 5.1.73-1

The URLs of the wikis are: - http://metterswane.iada.nl => The unupgraded wiki on the old host - http://metterswane2.iada.nl => The unupgraded wiki on the new host (first attempt) - http://metterswane3.iada.nl => The upgraded wiki on the new host (second attempt) - http://metterswane4.iada.nl => A fresh install of the newest MediaWiki version.

Unfortunately, the first three wiki's are password protected, and I am afraid I cannot share the URL. However, for the last wiki I have enabled registrations, so you can register and view the problem. For example the page http://metterswane4.iada.nl/w/index.php/Bestand:Appel.jpg is not accessible (even not after login).

Any help with this problem would be greatly appreciated. Thanks in advance.

Kevin

After some research I think I have identified the issue. I have placed a var_dump($_SESSION) in index.php to be able to view the session data on every page. For alle pages this is as to be expeced, except for the File: pages. In these cases I get an "Notice: Undefined variable: _SESSION in ...". It seems this is caused by the extension at the end of the URL. For example, the following URLs all work as expected:

• /w/index.php/File
• /w/index.php/File:
• /w/index.php/File:Test

But the following do not:

• /w/index.php/File:ExistingFile.txt
• /w/index.php/File:NonExistingFile.txt

I think this is due to a problem with my (shared) host configuration, that disables some of PHP's features if the URL ends in a non PHP related extension. However, I could fix the problem also if it is possible to overwrite the way the file URLs are build. If for example I could replace the dot for the extension with an other character (for example an underscore), then the problem would be fixed. Or even better, I also noticed that using the URL safe representation of a dot (%2E) simply works. For example, the URL /w/index.php/File:ExistingFile%2Etxt simply works and show detailed information about the file as expected. So if I could configure MediaWiki to always use %2E in the File URLs, then there would not be a problem either.

Is anything like this possible with the MediaWiki software?

You can use URL rewrites to translate dots into %2E when the URL is in /w/index.php/File:

That's something you can configure on apache, for example, with mod_rewrite

Fortunately my hosting provider has already fixed the problem. Some configuration concerning their Varnish cache caused sessions to be disabled when the URL ends on a static file type extension, even when the processing is actually performed by PHP. They now made an exception for MediaWiki, fixing the problem. Nevertheless thanks for your answer!