Not really a bad thing. I think the only downside is that the form becomes time-limited to the nonce lifespan? (ie. users leaving their browser open on the form for a long time may run into an error)
But testing a form is more difficult. For example,
/auth is hardcoded, which was also the case for the Node.js client, but the test suite would have to grow a lot of smarts to see that in a HTML form.
One of the things I had in mind was that the test executable could just be a shell script. I think I want to try that with the PHP library as well. But maybe it works too for simple testing with sinatra if the script can prepare a small app, then make requests with
curl.
Or selenium, I guess. Not sure what other options there are to test the form
Currently, the authorization endpoint isn't really implemented in the test suite broker, but we could do that and have it send a text response with the full URL it saw. That'd allow easy extraction and to respond to the test suite
auth command.
I had this whole issue with sinatra forgetting the nonce - because something triggers a session dismissal - and I wonder whether there is another solution, or whether testing could help pinpoint that better. In the other clients the nonce is not set to the form, but added to the request directly, but still stored at session level of course, right?
Now also testing PHP: https://github.com/portier/portier-php/runs/2510209787?check_suite_focus=true#step:14:1 😃
Didn't go for the shell script, though. The shell script idea was to reinvoke PHP for every request, like a real webserver, but would need to implement some sort of temporary storage like files. Seemed like a hassle.
Maybe that wasn’t entirely correct. You can do a session type thing if you use the
state param to recover the session. Most frameworks use a cookie, though. But maybe there’s a method to recover, or alternatively, create your own login session type thing, though then we’re full circle: could just use the nonce as the session key. 🙃
Kinda wish this was easier, because session storage is often super convenient. Instead, most clients libs I built have to find some alternate storage, like Redis.
The super nice thing about Go is that it's a snap to cross-compile for lots of platform
Plus, I already had the release process figured out for another project, so just copied it over, including multi-arch Docker images: https://hub.docker.com/r/portier/nginx-auth
I have been away from this too long. What's the design consideration for keeping it separate from the broker itself?
colemickens:matrix.org @colemickens:matrix.org saw the nixos mention, the saw nginx-auth
@colemickens:matrix.org lts functionality touches on 'user directory' type stuff, which I think is out-of-scope for what Portier itself wants to do. The nginx-auth code now only supports a plain text file containing emails, but I'm considering it for $work where we have a simple API for this. I imagine different people have all sorts of different ways of storing users, like LDAP, etc.
Just making sure, do you know about oauth_proxy?
The current approach is inspired by this post, which uses auth_request + vouch + okta: https://developer.okta.com/blog/2018/08/28/nginx-auth-request
I was installing a private instance of OwnCast, and wanted to secure it. The author of that post happens to be active in chat / github of that project. :)
Silly thing is, we already use auth_request to secure a private Docker registry at $work, but just with http basic auth. Never thought it could be used to implement a full form-based login flow.
Well, oauth_proxy specifically has a mode for use with this nginx feature where it doesn't actually proxy
It's used for exactly this scenario in kube scenarios
Just throwing it out there :)
Hetzner reported an outage and I can't reach our server, looking into it
Can't open the console for some reason
oh, it's back
Looks like everything came back up correctly. We were down a little over half an hour.
I also just got a mail from Docker Hub that Autobuild will be disabled for free accounts on June 18th. I think that's how we currently publish the portier/broker images. Kinda wanted to switch to GitHub Actions for that any way, but haven't had time to look into that.
I think I have a release script ready with some significant improvements. It'll cross compile for various platforms, and also push multiarch docker images. That should also solve the docker hub autobuild going away. Will be creating some test releases to actually test the full flow.
Going to upgrade our server to NixOS 21.05. Haven't had any trouble with other servers, so should be smooth
Logins still worked
colemickens:matrix.org @colemickens:matrix.org 🎉 nixos in the wild
Haha, of course. I also have my hobby stuff on nixos on hetzner, and we use nixos on AWS quite a bit at work. 🙂
The portier config is the first I ever wrote though. So some parts are a bit crude. 🙃