Closed hilli closed 3 months ago
Thanks for the report! I'll check it in Safari this weekend, I hope.
I think I might have found the problem, actually:
https://codedamn.com/news/web-development/safari-cookie-is-not-being-set
tl;dr: Secure cookies on http://localhost makes Safari ignore them.
So changing all &http.Cookie{ Secure: true }
to false
in handlers.go
made it work in Safari on localhost.
Maybe it should be an option to disable the secure cookies and do so in the example.
Yep, that sounds pretty reasonable :) I added a few new options, including withInsecureCookie
and updated README. That should allow playing around with the stuff on localhost, even in Safari. Thanks for the impact! :)
If you have any other ideas during your work with passkey, feel free to share them. It'd be great if we can make this library at least usable.
Thanks, nicely implemented!
And will do; Have you looked at
github.com/go-webauthn/webauthn
where it has a few methods with Discoverable
in them, ie WebAuthn.BeginDiscoverableLogin? Cordoba describes in https://www.corbado.com/blog/webauthn-user-id-userhandle#user-name-vs-user-display-name (Section 2.7.3, for which direct linking unfortunately is broken) a bit about setting it up as well as description of the process. I like the idea, since folks recollection of which login or email was used is sometime right along with the password - Forgotten. And it is a bit closer to the idea of a passwordless world. But, and I am not sure here, if the requireResidentKey
means that the user won't actually be able to login from any other device (In the Apple case, I'd expect any of the users iCloud synced devices would work tho).
So maybe not the best solution for a website where users expect to login from any device. But I'd like to hear what you think about it.
Yep, I read that article some time ago. But I don’t remember the details about working with BeginDiscoverableLogin
. I think it’s a great reason to delve into this topic more thoroughly.
Regarding login
, I’ve been considering for a long time to implement registration and login without giving the user a choice of what their UserID
will be. I'd like to add the ability to do this as anonymously as possible (without emails, phone numbers, nicknames, etc.). Of course, this will create some problems and inconveniences (losing the login, inability to recover access), but something can be figured out for these issues as well. I plan to write a proof-of-concept where the frontend application will generate a random UUID as the UserID
during registration. The user is expected to save it in their password manager, and the client application will save the UserID
in local storage with a high TTL.
Another interesting task seems to be the mechanism of associating multiple key pairs with one account. To better understand this, I want to implement it on top of WebAuthn using the library. You can see a very rough plan here: #3. It seems that after this, it will be easier to understand how to use Discoverable
correctly.
Unfortunately, it’s not clear right now when exactly I’ll be able to get to this. The week looks pretty busy. I hope I’ll find some time over the weekend :)
works in safari desktop for me btw. all good.
It was a problem with cookieSettings.Secure
. Safari ignores secure=true
cookie at localhost. Solved in #10. Now you can run server with WithInsecureCookie()
option.
It looks like we should close this particular issue. @hilli don't you mind, if I close the issue? :) I left the reference to our discussion about Discoverable
in #3.
Hey, following along here, since I like the first article, returned to it as I needed to make similar stuff and discovered this repo mentioned.
I was trying to get things working in Safari and they did not:
The same errors are presented in the browser. So I tried Chrome, and got it functioning. So just a heads up...