Authenticate with REMOTE_USER

[jbrooksuk]

Closes #3243

---

Right, so I've not written any tests for this yet, but I want to know if this is the right way of doing things since I've not got a method of testing.

Ping @jcmcken

[GrahamCampbell]

This doesn't seem very secure? All you need is someone's email, then you can login as them?

[jbrooksuk]

This doesn't seem very secure? All you need is someone's email, then you can login as them?

Which is what's leading me to believe I've done this wrong?

[GrahamCampbell]

I guess the point of this header is that it can only be set by the internal proxy. This middleware should definitely not be enabled in Cachet by default, and should be turned on only by those who are using Cachet behind such a proxy.

[joecohens]

What if we use the apiToken with this header as well instead of the email if the header is truly needed?

[jcmcken]

There are two general ways to do this:

• Using a header
• Using the runtime environment (an environment variable)

The first option requires you to set up the authenticating web server in a particular way. If the proxy and the app are co-located on the same machine, the app must run on 127.0.0.1 at a minimum. If not, more work is required (e.g. you must authenticate the proxy to Cachet or use layer 4 network protections).

The second option requires that the proxy and app are co-located and is generally more secure. Clients have no ability to set environment variables on the runtime process. Only the web server / runtime launcher can do this. Although it's Python, you can read the Django documentation which explains some of these issues (which are of course not language specific).

An excerpt:

Warning

Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server always sets or strips that header based on the appropriate authentication checks, never permitting an end-user to submit a fake (or “spoofed”) header value. Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

This warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = 'REMOTE_USER', since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header.

[jbrooksuk]

@jcmcken are you able to test this? :)

[jbrooksuk]

Ping @jcmcken!

[jbrooksuk]

@jcmcken I've fixed the conflicts, if you can please give this another go?

[jbrooksuk]

I'm going to merge this so we can move on with other bits. We can always look at creating accounts later on.