</offlist>

I'm too lazy to search for the archive links: here are the three
relevant links which do belong to your problem!

I just picked the newest one without reading the mail again.

Regards,

Dennis

On 18.10.2016 13:38, Nicolas Vervelle wrote:
> On Tue, Oct 18, 2016 at 1:09 PM, Dennis Roczek <dennisroc...@libreoffice.org
>> wrote:
> 
>> See deprecation message at:
>> https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-August
>> /000115.html
>>
>>
> Thanks for the reply, but I don't see anything related to my problem in the
> post...
> I do not pass parameters in the POST URI, but it the body, and I don't get
> any error or warning (except for the deprecation of action=login), it's
> just that the answer contains lguserid and lgusername but not lgtoken.
> 
> Nico
> 
> 
> 
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> 
--- Begin Message ---
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[1] 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 in
https://phabricator.wikimedia.org/T121527.


 [1]: https://phabricator.wikimedia.org/T55032

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

--- End Message ---
--- Begin Message ---
These response values, deprecated in December 2015, will no longer be
returned in the response to action=login. This change should be deployed to
WMF wikis with 1.28.0-wmf.13, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

Note that the lgtoken *parameter* to action=login is not removed, nor is
the 'token' response value included along with a NeedToken response.

This is expected to have a low client impact, since proper handling of the
Set-Cookie headers (rather than manually building cookies using these
response values) has been effectively required for some time now.


The original deprecation announcement is quoted below:

On Tue, Dec 15, 2015 at 11:11 AM, Brad Jorsch (Anomie) <
bjor...@wikimedia.org> wrote:

> 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[1] 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 in
> https://phabricator.wikimedia.org/T121527.
>
>
>  [1]: https://phabricator.wikimedia.org/T55032
>
> --
> Brad Jorsch (Anomie)
> Senior Software Engineer
> Wikimedia Foundation
>



-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

--- End Message ---
--- Begin Message ---
For improved safety, passwords and other sensitive fields for
authentication should not be included in the request URI during a POST.
Instead, they should be in the POST body where they are less likely to be
included in log files. With the merge of Gerrit change 305545,[1] the API
will now produce a warning if such fields are detected in the URI. This
should be deployed to WMF wikis with 1.28.0-wmf.16, see
https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap for the schedule.

This affects the following modules and fields:
* action=login: 'lgpassword'
* action=clientlogin, action=createaccount, action=linkaccount, and
action=changeauthenticationdata: Any fields reported as "sensitive" by
action=query&meta=authmanagerinfo or by UI or REDIRECT responses.
Currently, this affects the 'password' and 'retype' fields.

The 'lgtoken' field for action=login will now also issue a warning if
placed in the request URI. The error code for other tokens being in the
request URI has changed from 'mustposttoken' to 'mustpostparams'.

To check if your client's user agent is detected making such submissions,
you can also use ApiFeatureUsage[2] and look for
'<action>-params-in-query-string' once 1.28.0-wmf.16 is rolled out to wikis
your client is logging in to.

It is planned that these warnings will be changed to errors during 1.29.
Let's avoid having a repeat of T142155,[3] update your code ASAP instead of
waiting until it breaks. Thanks.

 [1]: https://gerrit.wikimedia.org/r/#/c/305545/
 [2]: https://meta.wikimedia.org/wiki/Special:ApiFeatureUsage
 [3]: https://phabricator.wikimedia.org/T142155

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Mediawiki-api-announce mailing list
mediawiki-api-annou...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

--- End Message ---
_______________________________________________
Mediawiki-api mailing list
Mediawiki-api@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Reply via email to