Previously there was a race condition where the qrcode would
not show if the startup module finished loading prior to the
div that should contain the qrcode being loaded. This quite
commonly happened on wikipedia during a hit where js is cached
(But does not happen locally, my theory is that that is due to
how packets get split over the network but not from localhost).
Change it to use a normal RL module, as that seems best practise.
Also do not load the qrcode js on special pages that do not use it.
Finially, remove position:top as its not needed.
Bug: T136988
Change-Id: I5139f222207203d834bdc979b21c1fc94f242ac2
Add RFC 3986 URI encoding to the account label in accordance with the
Google Authenticator specification to ensure the QR code is properly
generated for usernames with special characters in them.
Bug: T136269
Change-Id: I18175c9a3c9a45346fa7a227a5209194385c6696
We need to pass the db name to getConnection, in addition to wfGetLB.
Also, use core's CentralIdLookup for mapping local user to CentralId
when using a central DB for OATH secret storage.
Change-Id: I12a457633956a9a34dc5302ddcff468e31dd9cef
Users who started the "Enable two-factor" process, but never confirmed
their setup were stored in the database under the previous format.
After Ife5f1bae4ad65b66c5e20017cc43c0576b4aba19, we no longer look at
the is_validated column to see if the user confirmed their 2fa setup,
and instead only store users in the table who have confirmed.
Delete these users from the table when updating the table format.
Bug: T130892
Change-Id: I54a706043b44db50344d138207b472c35d00724e
During the two-step login, users with OATH enabled need to have their
login details saved into their session while we prompt them for their
OATH code. This encrypts that data, so we don't write their user's
password into our session storage.
Change-Id: I9969871205ac5c438706df41ef1519cb4cd7a964
Rather than have an extraneous form on the login page,
move the token input to a separate page. The actual
logic for logging in is identical, the only difference
is that the token is added to the form data on a second
page request.
Bug: 53195
Change-Id: I39859cc59f1811de42b72f6167d332ea48812f97
Make new right oathauth-enable that the user must have to enable two
factor authentication (disabling and logging in, of course, are still
allowed).
Bug: T100376
Change-Id: I18d43f8b2cf2c2ce9c2309a43961686498b5c999
Add configuration variable for specifying what database the OATH
credentials are stored in, that way wikis that use CentralAuth can
centralize their two-factor authentication data as well.
Bug: T100374
Change-Id: I285e2fe29fee43ddc6c5a6e51823911d43c596f6
