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!
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.
Doesn't PHP do that itself if the browser doesn't support cookies? (If you have the appropriate setting turned on in php.ini, anyway.)
Hi Yuri,
In my humble opinion, passing session information in a URL is a bad idea. This could lead to social engineering attacks "paste your address to me" where people can then get the Session ID and thus manipulate the user's login. This is why cookies are the default.
POST would probably work okay, though. But then, you'd have to use buttons to go anywhere on your site, and the code just starts becoming unmaintainable.
I would highly suggest that you just stick to the (default?) Cookie configuration...
In terms of external security risks, aside from the social engineering factor, if all the pages are viewed over HTTPS you should be fine. There is a bit of a problem when you start mixing HTTP and HTTPS using the same session, since somebody snooping on the connection could grab the Session ID via HTTP and use it to do nefarious things. But this applies to cookies as well.
Just make sure that you either use separate Session IDs for HTTP and HTTPS, and that you specify http:// and https:// respectively in your cookies, to ensure that session cookies tied to authenticated users won't be sent in-the-clear.
I hope this helps you. If you have any other questions, feel free to mail me off-list.
Regards,
Jonathan Yu
On 8/9/07, Yuri Astrakhan yuriastrakhan@gmail.com 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!
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
In my humble opinion, passing session information in a URL is a bad idea. This could lead to social engineering attacks "paste your address to me" where people can then get the Session ID and thus manipulate the user's login. This is why cookies are the default.
In general, you are right. However, I doubt if this api use will happen often: the api is an advanced *programming* interface, and not meant for general client use ;). I assume Yuri wants to introduce it because many simple (and even many more advanced) http client libraries do not support cookies.
POST would probably work okay, though. But then, you'd have to use buttons to go anywhere on your site, and the code just starts becoming unmaintainable.
Well, again, no. For api use this could be used, as the client can just add post data. It's not necessary to browse the entire wiki using this system, only api.php has to accept it :)
--valhallasw
wikitech-l@lists.wikimedia.org