Fri, Mar 27
Dec 25 2019
Nov 11 2018
Nov 5 2018
Oct 2 2018
Jun 9 2018
May 19 2018
Feb 20 2017
Feb 16 2017
Feb 15 2017
Note that the scratch tokens operate under a different attack scenario than TOTP codes, and thus they cannot be the same format.
Feb 9 2017
Jan 2 2017
Jan 1 2017
Dec 26 2016
Dec 19 2016
Note that this was achieved in https://gerrit.wikimedia.org/r/280672, so maybe this is more a bug with AuthManager than it is this extension?
Dec 13 2016
Nov 17 2016
I'm tempted to decline this, but maybe others feel differently.
Nov 13 2016
Nov 12 2016
It should be just that. I filed a bug for every difference between the two at the time.
Oct 12 2016
Is there some sense of a global site group name in CentralAuth? If there isn't then we should just have a config variable for this extension, rather than forcing the string "Wikimedia".
Oct 4 2016
I'd remove it. I really do not remember why I added it, and if I added it because of people accidentally blocking themselves...well that was a stupid reason. If people want to block themselves, maybe it's for the best anyway.
Sep 21 2016
Aug 13 2016
Jun 22 2016
Jun 3 2016
Is there a scenario in which this can be reproduced? Or is it seemingly random?
May 27 2016
I will check it out, although there's a strong possibility this was another bug caused by the lack of URI encoding. I will investigate and report back here.
May 26 2016
I've lost track of exactly what features AuthManager supports, but does it allow storing of arbitrary user authentication metadata? Because then once Extension:OATHAuth is converted to use AuthManager, we can just have the authentication provider store and fetch the secret from the generic backend interface.
May 24 2016
May 2 2016
Apr 19 2016
Apr 10 2016
Apr 7 2016
I am going to make separate tasks for some of the feedback.
Apr 4 2016
- Google: They allow login if you have one of any two-factors available (i.e., they support SMS and phone call as alternatives to TOTP). Additionally, when logging in with 2FA, Google allows you to mark a computer as "trusted". You can use a trusted computer that is still logged in to disable 2FA. Otherwise, you need to file an account recovery form, which Google responds to manually after a few business days. Things they ask on the form (I presume they have a further protocol beyond submission of the form, probably involving submission of government ID):
- The date you created your account and the date you last accessed it (required)
- Your security question, if enabled (optional, even if the question is enabled)
- Up to five email addresses you frequently contact and up to five Gmail labels you created (optional)
- Your first recovery email address (optional)
- Other Google products you use and approximately when you started using them (optional)
- An explanation of how you lost access to your account
- Contact information for sending the password reset
- Facebook: Submission of a government ID, or (strangely) you can take a picture of yourself holding a code that Facebook gives you.
- GitHub, Apple, and Dropbox: Does not offer account recovery at all. You either need a phone with SMS for backup, or another backup token of some sort. If you lose all of your 2FA, you have lost access to your account permanently.
- LastPass: They allow removal of 2FA from the account by just sending a confirmation email to the primary account email. If you lost access to your primary email, I am not sure what options are available.
- Amazon Web Services: You have to file a support ticket to remove 2FA, after which they call you on the phone and ask for some trivial verification information (such as your credit card number on file).
Apr 3 2016
Apr 2 2016
Weird, I don't remember claiming this in Phabricator. Although I can work on it if @01tonythomas wants.
The only interesting question about this is: what about users who are added as publishers to other newsletters by other people? Do we block a user from being added as a publisher when they reach the limit, or do we only block the creation of new newsletters?
Yep I believe so, unless there are other logging actions we wanted implemented.
Apr 1 2016
Literally the only place that error message is used is in the AbortChangePassword hook...
@Reedy Just so I know all the details, were you logged in already? And I presume your account has 2FA enabled on it?
@Reedy I cannot seem to reproduce this locally. Could you provide some reproduction steps? I've tried visiting Special:Userrights and other restricted pages while logged in and it did not bother me. All other functionality seemed to be working as expected.
Feb 24 2016
Jan 9 2016
Making public since the main bug this is a duplicate of is already public.
For some reason "wikipedia.com", and probably any other redirect domains the WMF owns, are not alt names on the certificate.
I have confirmed this in Chrome and Firefox. No warnings in Safari.
Jan 7 2016
I think this bug can probably be closed since the technical requirements have been fulfilled. However, I still think we should actually apply a specific strong policy to accounts.
Nov 19 2015
Nov 7 2015
@01tonythomas Just want to clarify. Should we as the mentors be rating these projects right now in the Outreachy application? And if so do we need to alter the Contribution status as well?
Oct 28 2015
I do not think @VitaliyFilippov's patches and the Outreachy project are mutually exclusive. First, I want to echo @Aklapper and just say thanks to @VitaliyFilippov. Patches are always welcome, and save us a bit of work!
Oct 26 2015
Sep 9 2015
Sep 4 2015
Just to clarify, that is completely false (in regards to the cookie being "malware").
Aug 25 2015
My only concern with this would be if there are any remaining browsers that preserve the HTTP method with 302 response codes. IE will only do so with non-POST/HEAD methods like DELETE and PUT, so there's nothing to worry about there.
Aug 11 2015
Aug 4 2015
Jul 1 2015
I agree that we should continue to have messages not be raw HTML, but that is a more general issue, and it does not really justify having an individual bug for every message that needs to be parse-ified.
Is there any consensus about whether a fix for this needs to be made (i.e., throw it through the parser and make a workaround for the little things)? Or can we close it as invalid considering, as has been noted, this is the least of our concerns with admin powers.