I would like some feedback on the issue of how to allow API users to prove who they are without using a cookie (some clients simply do not support them), but instead pass all relevant information in the URL/POST.
The login api module returns userID, userName, and userToken - all necessary parts of a cookie. The client should be able to pass those values in the URL, which should override the browser cookie (or lack thereof), and instead resume the session specified.
The $_SESSION object gets initialized based on the cookie before the php code starts. In order to resume the session, I could set $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken'] to the URL values, and set $wgUser = User::newFromSession() before any other operations.
Does this introduce any security risks? Is there another way to solve this?
Thanks!
Yuri Astrakhan wrote:
I would like some feedback on the issue of how to allow API users to prove who they are without using a cookie (some clients simply do not support them), but instead pass all relevant information in the URL/POST.
The login api module returns userID, userName, and userToken - all necessary parts of a cookie. The client should be able to pass those values in the URL, which should override the browser cookie (or lack thereof), and instead resume the session specified.
The $_SESSION object gets initialized based on the cookie before the php code starts. In order to resume the session, I could set $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken'] to the URL values, and set $wgUser = User::newFromSession() before any other operations.
Does this introduce any security risks? Is there another way to solve this?
Thanks!
This makes sense to me. Passing the ?PHPSESSID= query string should be a perfectly acceptable alternative to cookies; that's for what it was made. As for Jonathan mentioned, though: You might want to include the $_SERVER['REMOTE_ADDR'] in $_SESSION and then check it when authenticating the user. Bots' IP addresses should not be changing in the middle of a run, and it could prevent replay attacks like those he describes.
-madman bum and angel
Yuri Astrakhan wrote:
I would like some feedback on the issue of how to allow API users to prove who they are without using a cookie (some clients simply do not support them), but instead pass all relevant information in the URL/POST.
The login api module returns userID, userName, and userToken - all necessary parts of a cookie. The client should be able to pass those values in the URL, which should override the browser cookie (or lack thereof), and instead resume the session specified.
The $_SESSION object gets initialized based on the cookie before the php code starts. In order to resume the session, I could set $_SESSION['wsUserID'], $_SESSION['wsUserName'], $_SESSION['wsToken'] to the URL values, and set $wgUser = User::newFromSession() before any other operations.
Does this introduce any security risks? Is there another way to solve this?
Thanks!
Passing them as GET is always dangerous (having wsToken you can log in without the password).
I don't see how would that help cookie-less clients, which anyway would be rare (some example of them?) as you still need the session cookie (at least for editing). I had to add a dummy edit-request to my code to get it. I'm not so sure that you can _resume_ sessions without the session-id. Maybe add a login action wich outputs the session instead? (and add a parameter to treat as a cookie).
mediawiki-api@lists.wikimedia.org