Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Stéphan
@skochen:matrix.org
[m]
That's normal, it's running. If you want Docker to background it, add -d to docker run. You can also do something like --restart always to make sure it keeps running across machine restarts (or crashes). It's also useful to add --name portier-broker or something similar so you don't have to refer to the container with by some generated name.
Weird though, that you had to chown /data. Or were you doing that inside a container somehow?
You should now see a database file in /srv/portier-broker on the host.
1 reply
(really need to expand on that docker documentation, hah)
SF
@spencerflagg:matrix.org
[m]
i plan to add portier auth to a Nuxt site in the coming weeks. if all works out, i'll try to blog my journey
Stéphan
@skochen:matrix.org
[m]
Ah, cool, would love to see it! 😃
SF
@spencerflagg:matrix.org
[m]
i'm working with portier-node now. to point it to my self-hosted instance instead of broker.portier.io, do i need to do anything other than pass in a new broker param to PortierClient?
const portier = new PortierClient({
  broker: "https://portier.mydomain.com",
  redirectUri: "https://mydomain.com/login/verify",
});
1 reply
SF
@spencerflagg:matrix.org
[m]
:point_up: Edit: i'm working with portier-node now. to point it to my self-hosted instance instead of broker.portier.io, do i need to do anything other than pass in a new broker param to PortierClient?
const portier = new PortierClient({
  broker: "https://broker.mydomain.com",
  redirectUri: "https://mydomain.com/login/verify",
});
SF
@spencerflagg:matrix.org
[m]
are there any gotchas to serving the broker? i'm using Caddy to reverse proxy the docker image at port 3333, but i must be doing something wrong, because none of the broker's json files are resolving correctly.
3 replies
SF
@spencerflagg:matrix.org
[m]
Stéphan: just letting you know, your gitter.im lobby seems inaccessible. https://gitter.im/portier/Lobby throws a 500
and if you're still interested in listing sites that use Portier, i have an addition for you 🙂
Stéphan
@skochen:matrix.org
[m]
SF: Oh, sorry I never got back to you on that question! Did you get it working? Would definitely like to add to that list. 🙂
2 replies
I'm not sure what's up with Gitter, I can't even login on their site.
Stéphan Kochen
@stephank
Gitter is working again :)
Stéphan
@skochen:matrix.org
[m]
Going to upgrade the public broker to NixOS 21.11 now.
Looks good. Reboot was quick and everything appears to work.
onli
@onli
portier/portier-broker#269 <-- With a Ruby/Rack framework I'd be inclined to use a session there, and regularly fetch messages. Or probably I'd open a websocket for that.
Stéphan
@skochen:matrix.org
[m]
Yeah, we need something along those lines. Just thought I'd mention that feature there, because I don't think we made note of it anywhere else.
Stéphan
@skochen:matrix.org
[m]
Released and deployed Portier broker 0.6.0: https://github.com/portier/portier-broker/releases/tag/v0.6.0
onli
@onli
Very nice!
onli
@onli
@stephank, or maybe someone else ran into a similar problem: In pipes-digital/pipes#84 we discuss a problem with sinatra/portier in firefox, where the session seems to get reset after the redirect from the broker (and thus the login fails). I had similar problems before caused by rack-protection, but this time I'm stumped and there is no log output (that I can see). Just in case someone has an idea :)
Stéphan
@skochen:matrix.org
[m]
It could also be something browser-side. There are a lot of rules for which cookies are straight up rejected by browsers, and every browser is slightly different. :/
Does pipes.digital work when you follow the email login link on another device?
onli
@onli
It works when using Chrome, so there is definitely a browser component

Does pipes.digital work when you follow the email login link on another device?

In a second firefox instance for example? I will test that.

Not in my test at least. I'm not sure they were sufficiently isolated.
onli
@onli
but at the very least the test should have made certain that it's not the referrer tripping something
Stéphan
@skochen:matrix.org
[m]
I mention it because it's another way to bring up the issue. It's a downside of storing the nonce in the session, because if you go from laptop to phone for example, that session won't be there.
But that's a different issue I think. Even if login worked, the browser could still be dropping your cookies for some reason.
Stéphan
@skochen:matrix.org
[m]
I can't really seem to reproduce it unless I open the email link in a new private tab.
But the rack session cookie does have lifespan limited to the browser session. Is that intended? If you want it to be minimal, maybe setting it do something low like half an hour could already help here?
I'm also not sure if it's maybe a SameSite thing. Though that should default to Lax, maybe it'll magically help if you set it explicitely.
onli
@onli
It's intentional as in it was necessary to not have chrome browsers be unable to login ;) Same issue with them as now with FF, basically
There are console outputs that it's Lax (and it's the same site), but good thing to test!

I can't really seem to reproduce it unless I open the email link in a new private tab.

I think you are right: Since the login needs the nonce it can't work in a browser instance that does not share the session cookie database on the client.

Did you implement a solution in the PHP client that works without a session nonce?
onli
@onli
Yeah, I think that's the solution to all these problems, isn't it? I do not need to store the nonce in the session, I can store it anywhere. To check that the nonce is valid is enough. The user identity gets authenticated by the jwt without a nonce, the nonce just validates the login process. Or am I missing a security problem? I realize it's less secure in a way (the prior solution enforced logging in with the same client), but is that insecure or acceptable?
Stéphan
@skochen:matrix.org
[m]
Well, it's as designed. 😇 There are no security issues with it as far as I know, but I'm also no expert.
But I think it's also within OpenID Connect spec for implicit flow.
OIDC says the nonce is to prevent replay attacks. I suppose if we didn't have it, and someone intercepts a token, that token would be reusable until it expires.
Any way, in the Portier spec, I advise against using the session for nonce storage, exactly because a user may switch device.
Though, only as a SHOULD iirc, because I guess it's a choice. I have some apps at $work where we don't care and it's simpler to use the session. 🤷
onli
@onli
Okay. Thank you :) I'll test that out. Would be too great to finally solve this once and for all
onli
@onli
Stephan, you're great. Thanks, that really seems to have solved it and I just can't imagine future problems of this kind now
I'll report back to the pipes user and see whether he can confirm it
onli
@onli
Ah, I should link to the code changes: portier/sinatra-portier@08aa561
Would be great if you could scan over it. I tested the nonce handling (also the timeout), but this change is a bit sensitive
3 replies
Stéphan
@skochen:matrix.org
[m]
Yeah, I think adding redirect uri on top doesn’t hurt anything. 🙂
onli
@onli
I'll keep the workaround, but I'm fairly certain we just drilled down to the root issue - it's the enhanced tracking protection, the "cross site tracking cookies" option. Seems quite a few more people than I assumed have that activated, and it seems to be what drop the cookie.
onli
@onli
Not sure of course that there is not something in the Ruby/Sinatra stack that also killed the session sometimes after the redirect :/