Bugs item #3538008, was opened at 2012-06-25 21:52 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3538008...

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: James (jaclayiii) Assigned to: Nobody/Anonymous (nobody) Summary: *-login.data can have case discrepency on Linux host

Initial Comment: Pywikipedia [http] trunk/pywikipedia (r10401, 2012/06/21, 06:18:43) Python 2.7.2+ (default, Oct 4 2011, 20:06:09) [GCC 4.6.1] config-settings: use_api = True use_api_login = True unicode test: ok

Summary: the *-login.data file maybe saved with an uppercase username but when load cookies tries to find it on a Linux host, the case of the username maybe lower. This has the unintended consequence of not allowing bots to login on private wikis that have anonymous read api rights disabled.

If a user connects to a wiki that has LDAP or some other form of "add-on" authentication, the user name returned may vary in case from what is in the user-config.py file. The reason this matters is that the <wikifamily>-<language>-<username>-login.data file may be saved with an upper case letter in the username. Thus if the user-config.py file contained:

users["mywiki"]["en"]="james"

but the LDAP authenticator returned back "James" as the username, then the *-login.data file would be mywiki-en-James-login.data, but when _loadcookies goes to look for such a file on line 5572:

if os.path.exists(localPA)

localPA is /~some/path/to/mywiki-en-james-login.data

Notice that the James is now lower case in the file above.

As Linux is case sensitive, it cannot find the login data and thus prevents access to wikis the do not allow anonymous access to api's. A temporary work around requires setting user name to the appropriate case (even if the username is case insensitive in the LDAP authentication scheme), for example:

users["mywiki"]["en"]="James"

keywords: SSL, Login failure, https login failure, https linux login, https pywikipedia, https pywikipedia linux

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody) Date: 2013-02-12 19:23

Message: abEtXp <a href="http://clocxxourmmh.com/">clocxxourmmh</a>, [url=http://mhincreqjohj.com/%5Dmhincreqjohj%5B/url], [link=http://hpigicxvkgpm.com/%5Dhpigicxvkgpm%5B/link], http://tjgknhnocqum.com/

----------------------------------------------------------------------

Comment By: James (jaclayiii) Date: 2012-06-26 15:20

Message: After thinking even more on this issue, even for those not using LDAP authentication (which I would assume the majority are not using), correct casing based on the user-config file shouldn't have undesirable effects: if you can log in with what's in the user config file then correctly saving the cookie file with that username shouldn't negatively impact anything. On the other hand if you do not save the cookie file with the same user name that is in the user-config file, but you continue to use the user-config file to generate the localPA variable, then you may have problems on case sensitive platforms.

If this fix seems to difficult (I don't believe it to be) or you're suspicious of the logic, you may want to place a warning in the setup instructions. I've added a comment on the wiki for userconfig.py that people using *nix systems should be aware that by default mediawiki has uppercase user names.

----------------------------------------------------------------------

Comment By: James (jaclayiii) Date: 2012-06-26 12:08

Message: After rereading the LDAP link, you're probably right in that the it's the actual mediawiki login that is forcing uppercase, nonetheless the file name that pywiki attempts to find should be case correct irrelevant of the username supplied or returned. My thought for that fix has to do with correctly saving the *-login.data cookie with the username found in user-config.py.

----------------------------------------------------------------------

Comment By: James (jaclayiii) Date: 2012-06-26 11:59

Message: It has very much to do with LDAP: http://www.mediawiki.org/wiki/Extension:LDAP_Authentication/User_Provided_In...

And it has very much to do with Linux: Linux path names are case sensitive.

I reported the bug as it took me time to track down and perhaps someone else who has the misfortune of dealing with it will find this helpful.

The fact is that if I can login with a lower case name, and I can, then whatever pywiki stores should be in the same case, NOT what may be returned when the wiki user name is returned. The file name for *-login.data should be the same case as what is stored in user-config.py

This is just good practice, especially on a case sensitive host like Linux.

Also, as mediawiki is authenticating against LDAP, whatever it stores as the username is irrelevant if it correctly authenticates. A further reason to enforce correct casing based on the user-config.py file.

----------------------------------------------------------------------

Comment By: Merlijn S. van Deen (valhallasw) Date: 2012-06-26 03:27

Message: This has very little to do with Linux or LDAP, but rather has to do with the fact your username is 'James' and not 'james'. This is related to the 'first character is capitalized' convention on some wikis, but not all (!).

However, we could probably check whether the name has changed when the user is logged in and emit a warning when this happens (and/or store the cookie with the username as saved in the config file, but that could have some unintended consequences).

----------------------------------------------------------------------

Comment By: James (jaclayiii) Date: 2012-06-25 21:56

Message: Quick comment: _loadCookies() is in wikipedia.py on line 5534

----------------------------------------------------------------------

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3538008...