Last modified: 2011-03-13 18:05:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10308 - user authentication with tokens broken (API)
user authentication with tokens broken (API)
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Yuri Astrakhan
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-18 23:37 UTC by Stefan Bauer
Modified: 2011-03-13 18:05 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Fixes double parameter prefix in error message (2.04 KB, patch)
2007-06-19 14:12 UTC, Roan Kattouw
Details
Handle lgtoken and friends in ApiMain::__construct() (685 bytes, patch)
2007-06-19 15:30 UTC, Roan Kattouw
Details

Description Stefan Bauer 2007-06-18 23:37:26 UTC
using the login tokens retrieved with action=login does not work for me - neither in get or post mode.

I get the following error message with the tokens retrieved seconds before for an allpages query (values high to make sure I get an error):
"error":
"code": "apaplimit"
"info": "aplimit may not be over 500 (set to 50000) for users"

BTW: The code seems wrong too.
Comment 1 Stefan Bauer 2007-06-18 23:38:26 UTC
Sorry, forgot to add: I'm using a bot account.
Comment 2 Roan Kattouw 2007-06-19 11:29:07 UTC
Bot accounts are allowed a *five* thousand limit, not *fifty* thousand. I agree that the error should be "may not be over 5000" and the code should be "aplimit", I'll look into that later today. But however hard you try, 50,000 is never gonna work.
Comment 3 Stefan Bauer 2007-06-19 12:14:02 UTC
To value 50000 is an arbitrary value because I just wanted to the error message in this case to check my login status. I know the 500/5000 limit.
Comment 4 Roan Kattouw 2007-06-19 14:12:44 UTC
Created attachment 3801 [details]
Fixes double parameter prefix in error message

The attached patch fixes the "apaplimit" issue (which, BTW, was present with ALL modules: setting rclimit too high resulted in an rcrclimit error).

I'm still investigating the token issue. The token doesn't work for me either, but action=login also attaches a cookie to its response, which does work.
Comment 5 Roan Kattouw 2007-06-19 15:30:02 UTC
Created attachment 3802 [details]
Handle lgtoken and friends in ApiMain::__construct()

I've attached a (working) patch that fixes this bug, but the implementation is kind of hacky. ApiMain::__construct() checks whether lgtoken and friends are set, and re-inits $wgUser from the lg* data. This is done by copying the lg* data to the $_SESSION array, where User::loadFromSession() will eventually find it.
Comment 6 Yuri Astrakhan 2007-06-25 05:46:21 UTC
Fixed codes in r23358. Roan thanks for the patch but I had to modify it a bit to avoid introducing a new parameter in dieUsage(). Hope i didn't mess it up much :)
Comment 7 Yuri Astrakhan 2007-06-25 06:14:39 UTC
The login patch needs to be reworked -- all parameters need to go through the parameter parsing system - declared in getAllowedParams(), described in getParamDescription(). The question still remains why user cannot login using action=login. Also, if we decide to add the ability to login during query, the login process (parameter validation, creating session, etc) must go through the same code steps as action=login. For example, it could perform a nested api call just like feedwatchlist.
Comment 8 Roan Kattouw 2007-06-25 13:12:40 UTC
(In reply to comment #7)
> The login patch needs to be reworked -- all parameters need to go through the
> parameter parsing system - declared in getAllowedParams(), described in
> getParamDescription(). The question still remains why user cannot login using
> action=login. Also, if we decide to add the ability to login during query, the
> login process (parameter validation, creating session, etc) must go through the
> same code steps as action=login. For example, it could perform a nested api
> call just like feedwatchlist.
> 

getAllowedParams() will prepend a prefix (e.g. 'ap' for list=allpages) to the parameters, and we'll end up with aplgtoken, something I don't think we want. A user *can* login through action=login, that's not the problem. The problem is that passing lgusername, lguserid and lgtoken with every request after the login should allow the user to remain logged in, something that hadn't been implemented yet.

To illustrate:
1. I request api.php?action=login&lgname=Catrope&lgpassword=PASSWORD
2. I get back something like <login lgusername="Catrope" lguserid="1" lgtoken="123ABC">
3. I request api.php?action=delete&title=User:Catrope&lgusername=Catrope&lguserid=1&lgtoken=123ABC

This should allow me to successfully delete User:Catrope even if I don't pass a cookie on the second request.
Comment 9 Yuri Astrakhan 2007-07-06 05:05:44 UTC
I still fail to see what the bug is about. Upon successful login, session cookie is set by the server:
  enwikiToken=11111; enwikiUserName=Yurik; enwikiUserID=11111; enwiki_session=11111

Also, api returns 3 additional values that are not exactly needed because they duplicate the above (I am contemplating removing them). Note that session id is not returned.
 $result['lguserid'] = $_SESSION['wsUserID'];
 $result['lgusername'] = $_SESSION['wsUserName'];
 $result['lgtoken'] = $_SESSION['wsToken'];

When the next request is made, user's session is loaded from the sesion cookie, not from the parameters, and should work. If it doesn't, we have a bug in the code, which we should fix, but we should not introduce more code to work around it, unless there is a good reason.

Lastly, in case we decide to implement an ability to supply login/domain/password with each request, we can do it by manually calling the login module from the ApiMain in a "transparent" mode -- ApiLogin will analyze the parameters, decide if it needs to attempt a login, and return success/failure to ApiMain. ApiMain may then either continue with the requested module or stop.
Comment 10 Roan Kattouw 2007-07-06 11:03:17 UTC
I agree that sessions are probably the way to go. WONTFIX?
Comment 11 Yuri Astrakhan 2007-07-07 03:44:42 UTC
I will fontfix it for now. If the actual bug appears, feel free to reopen.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links