Primary issue is that the login token has been moved to the cookies and not
an actual token that needs to be re-used. hopefully that helps.
On Tue, Oct 18, 2016 at 7:40 AM, Dennis Roczek <dennisroczek(a)libreoffice.org
wrote:
> </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 <
> dennisroczek(a)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(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
> >
>
>
> ---------- Forwarded message ----------
> From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
> To: mediawiki-api-announce(a)lists.wikimedia.org
> Cc:
> Date: Tue, 15 Dec 2015 11:11:03 -0500
> Subject: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Removal of
> lgtoken, cookieprefix, and sessionid response values from action=login
> 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-announce(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>
> ---------- Forwarded message ----------
> From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
> To: mediawiki-api-announce(a)lists.wikimedia.org
> Cc:
> Date: Fri, 29 Jul 2016 10:38:02 -0400
> Subject: [Mediawiki-api] [Mediawiki-api-announce] BREAKING CHANGE: Removal
> of lgtoken, cookieprefix, and sessionid response values from action=login
> 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) <
> bjorsch(a)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-announce(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>
> ---------- Forwarded message ----------
> From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org>
> To: mediawiki-api-announce(a)lists.wikimedia.org
> Cc:
> Date: Fri, 19 Aug 2016 15:24:50 -0400
> Subject: [Mediawiki-api] [Mediawiki-api-announce] DEPRECATION: Passwords
> and other sensitive fields for authentication must be in the POST body
> 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-announce(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>