Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication #111

Closed
kashyap2108 opened this issue Aug 8, 2024 · 13 comments · May be fixed by #113
Closed

Authentication #111

kashyap2108 opened this issue Aug 8, 2024 · 13 comments · May be fixed by #113
Labels
enhancement New feature or request

Comments

@kashyap2108
Copy link

No description provided.

@bgentry
Copy link
Contributor

bgentry commented Aug 8, 2024

Not as of today. This is made clear in the docs but should be clearer in the readme. Recommendation is to either run it on a private network or front it with a zero trust auth gateway / reverse proxy setup.

We've talked about adding built-in support for CloudFlare Access as an auth option because that would be easy to do. I'm not sure we'll want to put a lot else in the main codebase though, because #107 would allow whatever auth schemes you can put in front of an http.Handler.

@cinemast
Copy link

cinemast commented Aug 23, 2024

Meanwhile, would you accept an PR that adds an optional basic-auth interceptor? This should be failry straigtforward to implement and would require only one or two additional ENV / config-parameters. I know the #107 is more elegant and flexible, but I guess for most people simple Basic Auth would be enough.

@bgentry
Copy link
Contributor

bgentry commented Aug 23, 2024

Yes I think some built in auth options would be fine. Maybe @brandur has thoughts on how these would be structured?

@brandur
Copy link
Collaborator

brandur commented Aug 23, 2024

@cinemast Can you talk about what your infrastructure setup would look like were River UI to add basic auth?

The main thing I'd worry about is that we add an auth layer, but only fake security because there's no out of the box encryption. So your user/pass is passed as plaintext and so trivially easy to steal that you may as well not have it, and we shouldn't provide it because some people might not understand this nuance and leave themselves accidentally vulnerable.

The only legitimate set up I can think of for this is something like Heroku where you have a router that handles encryption and an encrypted connection to a hosted node. But if you're on anything else where you're running your own reverse proxy anyway, you may as well just configure basic auth at the proxy level along with proper encryption (e.g. Nginx).

@cinemast
Copy link

cinemast commented Aug 23, 2024

That is exactly the use case yes, having it behind a loadbalancer that handles TLS/Let's encrypt setup but does not support Basic Auth out of the box.

e.g. Hetzner Loadbalancer is exactly that and what we are using.

Alternatively one can always throw Caddy in front of it of course, which offers TLS + Basic Auth, but this requires an additional container service which would otherwise not be necessary.

Totally agree that basic-auth without TLS is totally useless.

@travisby
Copy link

travisby commented Aug 23, 2024

In our case, we plan to run the river UI in kubernetes with istio in front of it to handle TLS.

If the UI gets broken out from its main and into something like an http.Handler interface, I'd love to wrap it in the auth0 SDK/middleware to provide an oauth scope/login in front of it.

Until then, I think I need to run it adhoc from my local machine when I need it!

@brandur
Copy link
Collaborator

brandur commented Aug 23, 2024

Got it. Okay, thanks — that makes sense.

@travisby
Copy link

(Actually, great idea with the "just run nginx in front of it". I might take that approach, I bet there's a simple auth0 plugin for that. And now it's just two containers in one pod, rather than one pod directly. Not a big deal!)

@brandur
Copy link
Collaborator

brandur commented Aug 23, 2024

Yeah, Nginx would work for a lot use cases. Pretty easy to set up nowadays and a healthy ecosystem of plugins for things like encryption and auth.

@brandur
Copy link
Collaborator

brandur commented Aug 23, 2024

That said, hopefully we'll have the http.Handler thing working sooner rather than later.

@cinemast
Copy link

Could we have #113 in the meantime? It would really simplify things a lot on my end.

@brandur
Copy link
Collaborator

brandur commented Aug 24, 2024

Yes I think we can do that. I'll review it soon.

@bgentry bgentry changed the title Do we have support of authentication ? When i deploy river Ui i can access it directly from browser. Authentication Aug 26, 2024
@bgentry bgentry added the enhancement New feature or request label Aug 26, 2024
@bgentry
Copy link
Contributor

bgentry commented Aug 29, 2024

As of v0.5.0, River UI can now be embedded as an http.Handler into any Go application. This means you can layer whatever authentication middleware in front of it that you'd like.

We will probably still move forward on #113 or other limited authentication options to make it easier to run as a standalone app, but given the wide variety of auth options out there our best advice is probably going to be that you should use the handler option to wrap the UI with your own middleware.

Check out the blog post to learn more: https://riverqueue.com/blog/river-ui-module-http-handler

@bgentry bgentry closed this as completed Aug 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants