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)
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
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",
});
: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",
});
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
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 🙂
I'm not sure what's up with Gitter, I can't even login on their site.
Looks good. Reboot was quick and everything appears to work.
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.
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.
Released and deployed Portier broker 0.6.0: https://github.com/portier/portier-broker/releases/tag/v0.6.0
@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 :)
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?
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.
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.
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.
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?
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?
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. 🤷
I'll report back to the pipes user and see whether he can confirm it
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
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