Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Stéphan Kochen
@stephank
I'm not aware of any Rust client so far! Don't think there is any reason it shouldn't work, though I'm not familiar with Actix.
Boscop
@Boscop
@stephank how much work would it be to implement a rust client for someone who isn't familiar with all the standards that are used? :)
Stéphan Kochen
@stephank
@Boscop Haha, uuuh, good question! I guess a day or two? Also depends on your level of perfectionism (docs, tests, etc.). But there's a bunch of code (in other languages) that serve as a reference.
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.
onli
@onli
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
Stéphan Kochen
@stephank
@onli Dang. We actually saw this as well, just didn't think it was a thing at the time, because all our user dbs are manually managed. We had to change an address or two. :/
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
Stéphan Kochen
@stephank
So between this issue, where an IdP could trash your account because they changed something in normalization/canonicalization, and that issue, where people can spoof accounts, I'm again torn about what's the right course here.
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.)
Stéphan Kochen
@stephank
So now I'm leaning towards: IdP normalisation is fragile, and maybe we should scrap it, and only do our own transform (from the normalization spec, basically lowercase and ascii)
onli
@onli
I think the behaviour I have with gmail now is okay - every address gets transformed to the base address. But the issue is that with other IdPs that won't be the same, right?

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
Stéphan Kochen
@stephank
It'll be the same for other IdPs, but they may use different rules. Whether they strip dots, remove a + suffix, or do something else, depends on the provider.
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.
onli
@onli
Oh. I did not think of that. You are right, that is problematic
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
Stéphan Kochen
@stephank
Thanks for picking that up! I totally let that linger in my inbox :)
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
onli
@onli
It might be useable for integrating a system with already existing accounts to portier
onli
@onli
*or rather, useful
but yes, it sounds right: just doing our own normalization should be the most stable option
onli
@onli
@stephank I thought about doing a small Show HN in the hackerforum, https://hackerforums.co/
Stéphan Kochen
@stephank
@onli Sounds cool! I'm a little short on time, though, so not sure I can help currently :)
onli
@onli
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?
Alexander Clouter
@jimdigriz_gitlab
not completely awful and not production tested, but https://gitlab.com/jimdigriz/portier-nginx
I manged to get it moving...mostly
a few things left to do with it, but it does what it says on the tin
onli
@onli
@jimdigriz_gitlab that looks really great
where do you create the login form?
onli
@onli
l.lua, found it
interesting file name scheme ^^
I would link to it from our project page, is that okay?
Alexander Clouter
@jimdigriz_gitlab
just moved it to webroot as it is a bit more friendly to edit there
@onli if you want to link to it, sure
naming scheme, my fingers hurt typing too much :)
onli
@onli
I hope this sees some deployments in production soon
Alexander Clouter
@jimdigriz_gitlab
I'll let you know when we deploy it at networkradius.com (to front Request Tracker), then you can add it to the list
onli
@onli
great, thanks
onli
@onli
heads up: I merged portier/portier-broker#174, which changed token['email_verified'] to be a boolean instead of the email address
onli
@onli
I just added a plugin for Ruby/Roda: https://github.com/portier/roda-portier