Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
onli
@onli
Are you aware of why? The concept behind portier is great, it works well in practice, and rust is not unpopular
Stéphan Kochen
@stephank
Well, I would say, we do near zero marketing. :)
onli
@onli
That might not help, true
Stéphan Kochen
@stephank
Apparently still had a bit more work to do, but here we go: https://demo.staging.portier.io :)
onli
@onli
That works :)
Stéphan Kochen
@stephank
I've set up a repo describing our public infrastructure. This currently applies to just staging, but I'll move our production environment over on May 11th. https://github.com/portier/public-infra
I also changed permissions on GitHub to reflect governance changes. Hope I didn't hurt anyone's feelings. 😇
Stéphan Kochen
@stephank
But if you're locked out of a repo that you are supposed to have access to, please let me know!
onli
@onli
okay
Stéphan Kochen
@stephank
I migrated production demo (https://demo.portier.io/) and will shut down the demo on heroku :)
Stéphan Kochen
@stephank
Actually have continuous deployment for staging setup on the server side. Pretty cool stuff. Just need to connect the GitHub side of things. :D
Stéphan Kochen
@stephank
CD is now working for staging for both broker and demo 🎉
And staging is now using the Postmark API instead of SMTP to send mail :)
onli
@onli
oh, what's the advantage of the API?
Stéphan Kochen
@stephank
According to docs, the API is quicker to produce an error for bad messages, while SMTP might accept and put it in a queue first. It's in the 'differences' section here: https://postmarkapp.com/developer/user-guide/sending-email/sending-with-smtp
onli
@onli
okay, nice
Stéphan Kochen
@stephank
The production broker is now running on Hetzner, and upgraded to 0.3.2 :)
Stéphan Kochen
@stephank
I imported the old RSA key, so it'll use that key today, and still announce it tomorrow. But it's now rotating keys daily, so after tomorrow that key is no longer valid. (I don't believe I've ever seen anyone hardcode that key.)
onli
@onli
I will have to take a second look at the ruby gem, that it still works :)
Stéphan Kochen
@stephank
@onli Btw, should I give you access to all the hosted stuff?
onli
@onli
@stephank Probably a good idea to reduce the busfactor, right?
btw, just had a new user with a . in the gmail address subscribe to pipes. Since the public broker is already changed that really seems to work fine
the normalization and the rotating keys
Stéphan Kochen
@stephank
Nice 👍
Stéphan Kochen
@stephank
Now have a test running every 5 minutes, that implements a small custom IdP: https://server.portier.io/stats.jsonl
Could make a nice graph out of that sometime :)
Stéphan Kochen
@stephank
@onli Hoping I can bother you to maybe do a quick read-through of the docs on the new config options here: https://github.com/portier/portier-broker/pull/210/files#diff-482d762113d87ccfaae28adb3c4a2262 🙂
Stéphan Kochen
@stephank
Wasn't expecting the IANA TLDs list to change that often, but it's like a weekly thing.
I noticed the DMARC spec references the same public suffix browsers use: https://publicsuffix.org
So maybe we should use that instead. And make it a run-time thing, so we bundle a version and read it on startup, allowing the user to update it independently.
Stéphan Kochen
@stephank
@onli Moar settings! 🎉 Hope you won't mind maybe reviewing the docs here again? 😇
https://github.com/portier/portier-broker/blob/7111ad531186d2ea7c5f40e995d19fda33ed1541/config.toml.dist#L132-L179
onli
@onli
@stephank of course not :)
Stéphan Kochen
@stephank
Ah, yes! Sorry :B
onli
@onli
To the overall change: If the suffix list changes as often, isn't it too problematic to rely on the user to update it?
Stéphan Kochen
@stephank
Hmm, good point. Maybe I misinterpreted the warning labels on publicsuffix.org about downloading too often.
Will have to think on that. I'm hoping for something simpler than another fetch & cache solution.
onli
@onli
I'm not familiar with that list and how it should be managed
I immediately thought of "download it on startup when no custom list is provided"
Maybe something I could try to implement?
Stéphan Kochen
@stephank
They talk about once per day, so I’m not to keen on doing it every restart. That may happen often during testing.
onli
@onli
oh, that would not work then
Dylan Staley
@dstaley
Does Portier have anything similar in concept to a refresh token? If not, is auth persistence something that's left up to the application to implement?
onli
@onli
In my apps that's completely up to the application, yes. Portier gives you the initial confirmation token and it's up to the app to translate that into a session. Recommendation was/is to keep that session alive for as long as possible.
Stéphan Kochen
@stephank
Same here. I think the only alternative is for Portier itself to have a session? But that's sort of what we're trying to prevent. It's one of the things that was confusing about Mozilla Persona, if I recall correctly.
Stéphan Kochen
@stephank
Thinking about the public suffixes thing, I guess we just have to fetch at an interval in the broker? I don't really see another way. (The only other thing I can think about is doing it outside the broker and adding SIGHUP config reloading support. While reloading is nice to have, having a separate thing to fetch the list complicates setup.)
But it looks like the list at publicsuffix.org doesn't have Cache-Control headers. So we probably want to add functionality to override cache age in our fetching code. Plus we should keep using stale lists if fetching fails.
Could probably do something crude to handle failed fetches. Like still set a Redis TTL, but x3 the cache age, and then allow 3 fetches to fail before crashing. No complicated retry timer logic for MVP.
Stéphan Kochen
@stephank
(Reason I don't want an infinite TTL is because changing configuration means old lists linger in the store forever.)