Problem/Motivation

First of all, I'm really excited about this module, I was wondering for a long time who will be stepping up to build passkey support for Drupal. Thank you so much @mingsong for doing it.

I started playing around with it right away, and I got it working, but with some difficulties and still an error that feels odd. Here is what I went through:

Installed the module and configured it for all roles on my test site. I only enabled the generic provider.

Then I went to my user profile and wanted to add a passkey to my account. The KeePass XC browser plugin popped up as usual, and I selected to register a new passkey. The Drupal site responded with an error message: Passkey registration blocked for disallowed AAGUID: fdb141b2-5d84-443e-8a35-4698c205a502

However, KeePass XC successfully created and added a passkey with all details in its database.

Then, I added a custom provider to the WA settings: fdb141b2-5d84-443e-8a35-4698c205a502|KeePass XC and that shows up correctly in the list afterwards. Only a config schema error was displayed, but that's for a separate issue. I deleted the record in KeePass XC and started again in my user profile. This time, I got a success message.

Then, I logged out and went to the login form, selected passkey login and the browser plugin popped up. I clicked OK to authenticate, and the browser showed a popup error: Error logging in: JSON.parse: unexpected character at line 3 column 1 of the JSON data. The same error message was in the browser console.

However, looking into the Drupal logs, it stated that the user logged in successfully. To verify that, I just refreshed the screen where seemingly the authenticated had failed, and voilá, the user was in fact properly logged in.

Not sure, what should be done next, but I hope my description helps you to find the reason for this issue. If you want me to test more things, please let me know. If it's easier for debugging, you can also PM me on Slack, where I have the same handle as here.

CommentFileSizeAuthor
#2 New provider.png65.83 KBmingsong

Comments

jurgenhaas created an issue. See original summary.

mingsong’s picture

mingsong
Location 🇦🇺
commented
StatusFileSize
new New provider.png65.83 KB

Hi @Jürgen Haas, thanks for testing it for me.

I wonder what version are you using when came across this issue? The latest dev version or the beta 1?

In terms of adding a new provider(Authenticator), there are two steps:
1. In the 'Additional AAGUIDs' input field, add the new provider as the below format for each line.
12345678-1234-1234-1234-1234567890ab|My Authenticator
And then save the configuration.

2. The new provider, in the example above, the 'My Authenticator' should appear in the 'Allowed authenticators' list at this stage. Then tick the box to choose the new provider just added.

New provider.

3. And save the configuration again.

looking into the Drupal logs, it stated that the user logged in successfully.

It seems that you have already added the new provider(device) successfully. But came across an error in the browser not in the Drupal log. If my understanding is correct.

Personally, I am really exited to this project as well. As you might know that so many people tried similar projects for years, but so far we haven't got any good progress on it. I think one of those challenges is that there are so many devices, plugins and password manage apps need to test to ensure a decent compatibility.

In your case, I am assuming you are using a Chrome extension
https://chromewebstore.google.com/detail/keepassxc-browser/oboonakemofpa...

I haven't tested that, If you can confirm it, I will give it a try to debug it out.

Thanks again, let's work together to make this happen.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

Thank you for your quick reply. I've tested with beta1, should I try that again with the dev release?

Steps 1-3 is what I've done. After that, authenticating with passkey works, so the session gets started in the backend. But in the browser, the user sees the error message about a malformed JSON and it looks as if the login failed. But it succeeded, and refreshing the page shows the user that they're logged in. So, I assume, if we can fix the JSON error message, all should be resolved.

In your case, I am assuming you are using a Chrome extension
https://chromewebstore.google.com/detail/keepassxc-browser/oboonakemofpa...

Yes, that's the one. I'm using that on Firefox, but the basics are the same. That browser plugin acts as a bridge between the browser and the desktop app from https://keepassxc.org/

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

Ah, I think I found what's happening. This is not an issue with KeePass XC, it's a problem that happens when the Drupal site has a mechanism to redirect users after login. There are different modules around who do that by responding to the login hook.

So, the JS from this WA module sends a POST request to /verify and expects a json response. As part of that request, the Drupal site starts a session and logs the user in. But that triggers the redirect, so that the original POST request turns into a GET request which responds with an HTML page and not the expected JSON. That's why the javascript in the browser fails.

As a solution, you may want to split the verify steps from the login step, that should then work as expected.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Title: Problems with KeePass XC » Authentication seems to fail when Drupal redirects in response to a login

Confirmed, I've just tried this by disabling all redirects, then the login works as expected.

  • fd4a4133 committed on 1.0.x 
    Issue #3559460 by jurgenhaas, mingsong: Authentication seems to fail...
mingsong’s picture

mingsong
Location 🇦🇺
commented

I just pushed the fix for this issue to 1.x dev branch. When you have a chance, could you update to the latest dev release to test this again?

Thanks.

mingsong’s picture

mingsong
Location 🇦🇺
commented
Status: Active » Postponed (maintainer needs more info)
jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented
Status: Postponed (maintainer needs more info) » Needs work

Not yet, I'm now getting this error in the browser console:

DOMException: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. page-observer.js:29:31
    addConsoleError moz-extension://d94f9d04-a3f4-4562-8a57-d42e2062d6b2/page-observer.js:29
    attach https://domain/modules/contrib/wa/js/passkey.js?v=1.x:231
SyntaxError: JSON.parse: unexpected character at line 3 column 1 of the JSON data page-observer.js:29:31
    addConsoleError moz-extension://d94f9d04-a3f4-4562-8a57-d42e2062d6b2/page-observer.js:29
    attach https://domain/modules/contrib/wa/js/passkey.js?v=1.x:231

And the approach in your code may be getting there for redirects, but there may be other use cases where a login during /verify can be problematic. Imagine a scenario where the Drupal site is an OAuth server. At that point, the redirect after login goes back to the site that asks for authentication. If that gets mixed up with logic from WA, then we could run into confusion.

Therefore, I suggest looking into an additional step in the flow: when you POST to /verify, just do the verification without a login. IN case the verification is successful, respond with a one-time login URL, and the client would then redirect to that, which finalizes the login. Or something similar to the last step, maybe implement your own safe login URL after successful verification.

mingsong’s picture

mingsong
Location 🇦🇺
commented

I think you are right. Calling the user_login_finalize() during an Ajax call probably is not a good idea.

Thanks for your help. It seems that I need to refactor the login process.

mingsong’s picture

mingsong
Location 🇦🇺
commented
Status: Needs work » Fixed

Hi @Jürgen Haas, I think I fix this issue with Beta3.

I tried the following contrib modules with Beta 3 to redirect user to a URL after signing in.

https://www.drupal.org/project/user_redirect

https://www.drupal.org/project/login_destination

According to my own tests, the login redirect function working well with Beta 3 and other modules.

Could you try it again with Beta3 to see if it is fixed for you as well?

If there is still issue with your site, please feel free to re-open this ticket with as much details as possible. Such as what modules involved.

Appreciate reporting and helping me on this issue.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

jurgenhaas’s picture

jurgenhaas
he/him
Primary language German
Location Gottmadingen
commented

This is looking great now, thanks a lot.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.