Also, going async in Rust probably adds time, unless you're proficient. The current async system is still quite complicated. I'm excited for async/await in the language, but that's probably going to take a while still.
I just got bit by the + change. A user had data under an email user+service@gmail.com, but when he now logged in that data was inaccessible, since my service thought he logged in as user@gmail.com.
But that behaviour was the intention, no? Or should the ruby/sinatra client have reused the email the user entered?
It is using id_token['email'] currently, thus working with the normalized email that comes from the broker - I think that came from basing the decision of the match on the nonce, and was for better consistency with the other clients
I think, as long as validation completes successfully, whether you use
email or email_original is up to you.
We had a discussion at the office about this, because at the time, this article was making rounds: https://jameshfisher.com/2018/04/07/the-dots-do-matter-how-to-scam-a-gmail-user
I guess, spoofing accounts is actually not an issue in our case? Because in the Netflix example from the article, they simply never verify they email when registering. Whereas, verifying the email is exactly what we do and the purpose of Portier.
But, at the same time, I worry about UX, when a user changes capitalisation (or some other detail that doesn't matter for the address) and suddenly gets a new account. (I've seen plenty of sites not use the correct HTML input tag, and treat input on mobile as normal text, capitalising the first char of the address.)
But, at the same time, I worry about UX, when a user changes capitalisation (or some other detail that doesn't matter for the address) and suddenly gets a new account.
I agree, that's bound to be confusing
in my case the user wasn't sure anymore whether he used a +prefix or not at the beginning
But, I'm now thinking, as we get more providers on board, it'll break more existing accounts. Users that previously used email verification to login using say,
foo+bar@example.com, will suddenly start logging in as foo@example.com.
Btw, I answered portier/portier.github.io#34
for the email normalization: In my mind there is no clean solution. On the one hand, you do not want thinks like lowercase instead of uppercase lead to a new account. On the other hand, switching
foo+bar@example.com to foo+bar@example.com really is problematic sicne the broker can't easily react to that
So, I guess we should, like, trash provider normalisation completely? And only do our own. That's spec'd, not too fancy, and will always result in consistent broker output, no matter wat providers do.
Or is it useful to keep around as an extra field, noting that it should never be used as an identifier?
Though, I feel like that'll only cause confusion
but yes, it sounds right: just doing our own normalization should be the most stable option
it was a small thread, https://hackerforums.co/show-hf-f7/show-hf-portier-a-spiritual-successor-to-mozilla-p-t136.html. Should we discuss some of the PRs we got?
I manged to get it moving...mostly
a few things left to do with it, but it does what it says on the tin
where do you create the login form?
interesting file name scheme ^^
I would link to it from our project page, is that okay?
@onli if you want to link to it, sure
naming scheme, my fingers hurt typing too much :)
I hope this sees some deployments in production soon
heads up: I merged portier/portier-broker#174, which changed
token['email_verified'] to be a boolean instead of the email address