Page MenuHomePhabricator

Remove deprecated response values from ApiLogin
Closed, ResolvedPublic

Description

Long ago, the only mechanism for session management in MediaWiki was certain cookies set by the User class. When ApiLogin was written, in addition to setting these cookies as usual it also returned some of the values needed to construct these cookies on the client. Presumably this was to make things easier for clients that somehow couldn't handle the standard cookie headers.

Then CentralAuth came along. Now, constructing the cookies manually would log you in to the local wiki only, without taking advantage of the SUL mechanism.

Then T55032: Multiple users with the same session ID happened, and clients that were using the manual-construction mechanism had to update their code because one of the cookie names changed and that wasn't part of the data being returned.

And soon, we'll have SessionManager and AuthManager, which will make it possible for login to easily happen in ways that don't involve cookies at all.

So it's time to eliminate the pretense that clients can manually construct the cookies instead of handing the standard HTTP cookie headers. Tentative plan is to deprecate them now and then remove them sometime during 1.28; if anyone objects to this schedule, please raise your concerns on this task.

Event Timeline

Anomie claimed this task.
Anomie raised the priority of this task from to Needs Triage.
Anomie updated the task description. (Show Details)
Anomie added a project: MediaWiki-Action-API.
Anomie moved this task to Blocked on the MediaWiki-Action-API board.
Anomie subscribed.

Change 259272 had a related patch set uploaded (by Anomie):
ApiLogin: Deprecate certain response values

https://gerrit.wikimedia.org/r/259272

Change 259272 merged by jenkins-bot:
ApiLogin: Deprecate certain response values

https://gerrit.wikimedia.org/r/259272

Anomie set Security to None.

For the record, this is now blocked on "wait for 1.28 so we can remove the stuff, pending any objections".

@Anomie: it would be good to document what 'removal of lgtoken' means exactly, as there are two (different) lgtokens. As I understand it, lgtoken in the return value (which would go into a cookie) is being removed, but we keep the (XSS) lgtoken passed by the client to api.php?

The XSS lgtoken is a request parameter, not a response value.

csteipp added a parent task: Restricted Task.Jan 8 2016, 3:32 PM

For anybody else who comes here horribly confused:

  • The token property in response of first login step is NOT deprecated, and still has to be used for the lgtoken parameter of the second login step.
  • The lgtoken property in response of the second login step is deprecated, and must not be used for anything.

So it's time to eliminate the pretense that clients can manually construct the cookies instead of handing the standard HTTP cookie headers.

Could anyone point me to documentation on what " handing the standard HTTP cookie headers" means? I built a JS library that was taking advantage of manually constructed cookies, and now it's broken, so I would be glad to update it to the long term/future-proof version

Thanks in advance for any help!

Maxime

In T121527#2018202, @Zorglub27 wrote:

Could anyone point me to documentation on what " handing the standard HTTP cookie headers" means? I built a JS library that was taking advantage of manually constructed cookies, and now it's broken, so I would be glad to update it to the long term/future-proof version

As far as I can see, you are using the standard HTTP cookie headers (you're parsing the set-cookie header). The old-and-incorrect way was to manually build a cookie from the content returned by the API.

As far as I can see, you are using the standard HTTP cookie headers (you're parsing the set-cookie header). The old-and-incorrect way was to manually build a cookie from the content returned by the API.

That's correct.

I'll add that if you're writing your own code to parse set-cookie headers, do make sure that you properly implement RFC 6265, particularly with respect to what happens if you're served an already-expired cookie.

Change 301393 had a related patch set uploaded (by Anomie):
API: Remove deprecated response values from action=login

https://gerrit.wikimedia.org/r/301393

Change 301393 merged by jenkins-bot:
API: Remove deprecated response values from action=login

https://gerrit.wikimedia.org/r/301393

Change 303317 had a related patch set uploaded (by Gergő Tisza):
Revert "API: Remove deprecated response values from action=login"

https://gerrit.wikimedia.org/r/303317

Change 303320 had a related patch set uploaded (by Gergő Tisza):
Revert "API: Remove deprecated response values from action=login"

https://gerrit.wikimedia.org/r/303320

Change 303320 merged by jenkins-bot:
Revert "API: Remove deprecated response values from action=login"

https://gerrit.wikimedia.org/r/303320

Change 303317 merged by jenkins-bot:
Revert "API: Remove deprecated response values from action=login"

https://gerrit.wikimedia.org/r/303317

Multichill subscribed.

Reopened this one because it was the change was reverted for T142155 . This should be implemented in the future, just not now.

Anomie moved this task from Needs Review to Blocked on the MediaWiki-Action-API board.
Anomie added a subscriber: Tgr.

This should be implemented in the future, just not now.

It was announced seven months ago. People should really update their stuff when deprecation is announced, instead of complaining when the deprecated code is removed.

I'm going to reassign this to you, @Tgr. You can unrevert whenever you're ready.

Change 314647 had a related patch set uploaded (by Gergő Tisza):
API: Remove deprecated response values from action=login

https://gerrit.wikimedia.org/r/314647

Change 314647 merged by jenkins-bot:
API: Remove deprecated response values from action=login

https://gerrit.wikimedia.org/r/314647