I created follow up tasks for this extension under the new PasswordlessLogin tag, so I think this task (as a hackathon task) can be closed :)
May 21 2019
May 20 2019
May 19 2019
May 18 2019
Working on it :)
I'll take a look into it. It is totally possible that I simply missed tht during the implementation and changes of this feature :)
The source code of the extension (build during the hackthon) can actually be found here:
Making the file to contain an empty array does probably match your use case, as you (my assumption) does want to check for a TLD domain already (e.g. mymailserver.de). However, if you need to whitelist a specific subdomain only, you need this file. The preficxes are used by GoogleLogin to find out what the parts of a specific domain are, e.g., mymailserver.co.us, where mymailserver is the host and co.us is the TLD. If the co.us isn't known as a TLD, GoogleLogin (when not in strict mode) would allow all domains of co.us to login with Google on the wiki (as it would think that co is the host and us is the TLD).
It's also mentioned in the corresponding configuration option.
Btw.: Please do not assign tasks to people directly :) If a person wants to do a task, they most likely assign themself :) Thanks! :)
Having HTML messages opens a wide door of variations and "stuff" people can do with it. Can I kindly ask, why these links can not be on the "More information" link page?
I would love to see this as a 2FA feature (eg. you want to save Common.js, MediaWiki sends you a phone notification asking whether you are really trying to do that, you tap through - it's a far less painful alternative to going through login / OATH again, which is what we are currently doing as a security check).
Maybe it can be built on the top of T113125: Investigate using service workers to provide real-time Echo notifications in the browser (push notifications)?
Note Wikimedia will probably serve push notifications soon (currently planned for 2020 spring) so maybe time to think about some sort of push service in core.
May 15 2019
May 7 2019
First of all: Yes, this would be for Android only, and please see this more or less as a Proof-of-Concept, about a theoretical idea I had. I want to implement this during the hackathon, and for me it means, that it is not locked to a specific vendor and has the possibility to be ported to other devices, too (at least the APIs needed would be open to be used I think).
Apr 8 2019
Apr 5 2019
Mar 21 2019
Mar 16 2019
I've found the same issue while trying to migrate jobs from the trusty grid to the new one (or better deleting the tool at all) :/
Feb 9 2019
Jan 31 2019
Yes, I'm available.
Jan 27 2019
As far as I know, this is already reflected in the current code base, as it does not require the profile permission anymore, and does not request it either, since:
I think, because:
- I get a lot of requests to autolink accounts, mostly from private wikis, which want to use GoogleLogin as it's only primary provider
- the implementation of an "create account after link provider authentication" UI (T138678: AuthManager should support to create a new account for a Link PrimaryAuthenticationProvider) may take some more time to get implemented
The documentation is correct from my point of view. If you check the keep me logged in checkbox, you will be kept login even if you use GoogleLogin to login. However, if you remove all authentication methods (which bypasses the Login form completely for convenience of the users) you can't check this checkbox.
Jan 8 2019
I wasn't very active this year, either. However, if no-one else has time or is interested, I'd be happy to attend, nevertheless.
Jan 2 2019
Nov 13 2018
Nov 11 2018
Nov 4 2018
Oct 28 2018
Oct 25 2018
There's a design prototype on wiki: https://m.wikidata.org/wiki/Wikidata:Client_editing_prototype
Oct 23 2018
Imported as https://codein.withgoogle.com/dashboard/tasks/6289154326396928/ for Google-Code-In
Oct 1 2018
Sep 27 2018
Sep 16 2018
Found this issue, too, I'll add these messages in a patch and upload it in a second :)
Sep 1 2018
Aug 11 2018
Coming from ULS, not CookieWarning.
Aug 6 2018
Already working on it...
Aug 2 2018
Jul 26 2018
Jul 23 2018
Jul 22 2018
Jul 21 2018
Jul 20 2018
Btw.: It seems you don't have the latest master version, latest master does not contain the CookieWarningDecisions class anymore, but instead the Decisions class.
First of all: I kind of thought, that you can already set an e-mail address only to one user, so that there's a one-to-one-relation from one user to one e-mail-address and vice versa. However, this turns out to be a wrong assumption. I'll cover the obligations resulting from that in the following answers to the comments :)
Jul 19 2018
Thanks for the response :) Great to hear, that the problem is fixed :)