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=353800…
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-03-13 06:44
Message:
I have been taking Japan Lingzhi 2 Day Diet
http://udaydiets.cocolog-nifty.com/ for a week and lost 5 pounds.the
initial issue within the morning is take this pill with an empty stomach
and it appears to create my appetite disappear. this is considerably
stronger than any other merchandise. and i choose to take 2 tablets within
the future.
----------------------------------------------------------------------
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_I…
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=353800…