Fri, Feb 21
Thu, Feb 20
Tue, Feb 18
Thu, Feb 13
Wed, Feb 12
The patch above will let you manually configure the relying party name and id (domain). It can be set to the root part of the domain, to make WebAuthn work for multiple sub-domains, while without it, it can be used on one specific subdomain only. So, it does add some functionality, but still not as much as you would need.
Tue, Feb 11
From what i discovered until now, that is not possible, limitation built in webauthn standard. You get an attestation in the key for the specific relying party with whom the key was registered.
What is the setup where you are using this. Are all wikis on mediawiki.org domain, with just different subdomains or on completely different domains. If they are all just different subdomains, we can use the configuration solution.
I tried the solution i suggested before, and actually it wont work. Browser checks the RP id agains the current domain and wont allow any operations if the two dont match. I dont have an idea now on how to make this work.
I have tested this and can confirm the issue. RP id (domain in this case) is baked into the credential so there is no way to use the same key on multiple domains currently.
What we could do is t make relying party id configurable, so that all wikis using the same DB could set the same key, and therfore use the same keys between each other.
Ah, ok, tought it was more complex :) Thank you guys, ill give it a shot
From what i remember, and from a quick search now, relying party is only used for "signing" the requests during registration/authentication processes, so that the server knows that it was the one that the request originated from. It should not be saved to the db.
If we dont specify the server id, it will fall back to $request->getUri()->getHost() which would come to the same value.
Hello, i dont understand why $wgServer wouldn't work, could you explain? When user tries to authenticate it takes the $wgServer of the wiki request was made on, and later compares that to the domain from the request URL. Why would this be different, unless the request is not started on one wiki and completed on another. Thanks
Mon, Feb 10
Tue, Feb 4
Fri, Jan 31
Wed, Jan 29
This is only presetnt in version 4.6, not in any of the current branches
Tue, Jan 28
Submitted a patch with the proposed fix
Mon, Jan 27
Jan 21 2020
Jan 20 2020
Dec 20 2019
Nov 9 2019
Great! Yes, probably all DB access should go through OATHAuth, especially since this is just reading all keys. I will commit a patch for that in the following days
Nov 8 2019
Thank you, i got in.
I would like to know if this line is executed or not
I guess i would need to put some debugging statement in there
I managed to log into bastion-eqiad1-01, is that the right server? How do I get to WebAuthn from there?
Can you please provide me with the shell access?
I debugged locally the whole path of authentication and this seems like an impossible bug...
if the statement from the previous post is true, that means that key is found that would mean that this condition is true
Nov 7 2019
Thank you for admin access, now i do have the option to enable 2FA.
This error occus after calling https://github.com/wikimedia/mediawiki-extensions-WebAuthn/blob/master/src/WebAuthnCredentialRepository.php#L66-L71
It appears this does not return a valid credential.
From how PublicKeyCredentialSource::createFromArray works, it would either return a valid credential or throw another error, so my guess given credentialId is not found in the DB
Seems that relevant messages are written to log at this level, this is the error coming from the library, just unfortunatelly, not very helpful
How can i set up WebAuthn for myself on https://en.wikipedia.beta.wmflabs.org? (i dont see the entry for 2FA)
I have just updated our dev system to master and pulled latest versions of both extensions, and was able to login normally using my phone's fingerprint sensor (left the FIDO key in the office).
I did some debugging and found out that verification will fail when php extension gmp is not enabled. However, without it you would not be able to register the key in the first place.
Verfication failed occurs when authentication ceremony fails, most likely in the library. ( MediaWiki\Extension\WebAuthn\Key\WebAuthnKey::authenticationCeremony).
Any error coming from the library should be logged into the logger, on channel 'authentication'. Can you check the log?
Also, please check the DB if the key has been saved correctly
Nov 4 2019
This error occurs when module that user has registered cannot be instantiated, like if WebAuthn module has been enabled, and user enabled it, but then WebAuthn was disabled.
Oct 28 2019
Yes, support check is done very early, before any of the fancy code gets executed
Oct 25 2019
Removed all (hopefully) ES6 features. However, any browser that supports WebAuthn is likely to support ES6 as well
Oct 23 2019
Did not find any orphaned messages in OATHAuth extension
This was set up to ask for re-auth only on "enable" action, but the action remains the same even after the form has been submitted, and if it happens that re-auth period expires between starting the enabling process and submitting it, then is when this issue will occur.
Sep 20 2019
Switched to jsonSerializing objects before putting them into session.
These changes are made on top of existing changes to avoid merge conflicts
Sep 18 2019
Hm, it cant be an array, key can only be generated from
Sep 11 2019
Should we provide a warning when enabling a 2FA method, in case you already have one enabled?
Sep 4 2019
This should do it. Make sure type is actually what we expect, and not just "not null"
Aug 28 2019
Re-introduction of empty "Available methods" section is now fixed
Aug 3 2019
Sent a mail to both lists
Edit: well I guess i cannot send mails right after subscribing to the lists. I will try again later, or someone else can send the mail
@JoeWalsh Due to refactoring and moving towards namespaced classes
class name is expected.
No refactoring was done (from our side) on Wikipedia apps
Jul 31 2019
Is this issue still relevant? This message key is actually not used anymore, as error SpecialPage is gone now. I could not reproduce the issue
Jul 17 2019
This warning indicates that database table (oathauth_users) is not updated
Jul 10 2019
@Sebastian.Schmid91: Thank you for opening this ticket.
The issue is resolved in the patch above
Jul 4 2019
This is fixed in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/OATHAuth/+/499183/30/src/Special/OATHManage.php L124
Whole section is not added if its empty.
It could have regressed in later commits, i will pay attention to this as commits get merged
Jun 28 2019
Jun 24 2019
Jun 19 2019
Jun 13 2019
Jun 12 2019
Recently, requirement for ExtJSBase in BlueSpiceFoundation@REL1_31_dev was changed to "~3.1" which should match version "1.34" of ExtJSBase@master, but the tests still fail with the same error