Safari issues

[hilli]

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:

2024/07/27 10:34:01 INFO: begin registration
2024/07/27 10:34:08 ERROR: can't get session id: http: named cookie not present
2024/07/27 10:34:22 INFO: begin login
2024/07/27 10:34:22 ERROR: can't begin login: Found no credentials for user
2024/07/27 11:40:09 INFO: begin registration
2024/07/27 11:40:15 ERROR: can't get session id: http: named cookie not present

The same errors are presented in the browser. So I tried Chrome, and got it functioning. So just a heads up...

[egregors]

Thanks for the report! I'll check it in Safari this weekend, I hope.

[hilli]

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.

[egregors]

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.

[hilli]

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.

[egregors]

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 :)

[gedw99]

works in safari desktop for me btw. all good.

[egregors]

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.