Private mode

[Olivier Mehani]

Here is a first cut at requiring login before seeing content.

It adds a configuration option, require_login, which, if set, prevents media and listings from being displayed to anonymous visitors.

It also doesn't output any entry in the RSS feed, which could otherwise be used to discover paths to the media.

I realised fairly late that this sort of behaviour could be implemented through decorators (probably as a light superset to @require_active_login, checking the config). At the moment, this is mostly implemented within the Jinja templates, rendering login pages where listings should be, rather than blocking the entire page.

Let's discuss what the best approach is!

[Ben Sturmfels]

This would be a really nice feature to get into 0.11.0, so I'll tentatively tag it for this milestone.

[Ben Sturmfels]

Thanks for proposing this Olivier; it's something I've been wanting for a long time.

If we're providing a private mode, I think we need to bring the media files in too. If I didn't know how MediaGoblin worked, I would find it surprising that you could anonymously access the media files directly given the URL.

Given that MediaGoblin docs are oriented towards Nginx, I'd suggest we add support for Nginx's X-Accel (a.k.a. X-Sendfile). This means that all requests for media first go to the MediaGoblin app for authentication, but then MediaGoblin responds with just a header like "X-Accel-Redirect /srv/mediagoblin/user_dev/media/public/secretphoto.jpg". Nginx picks this up and efficiently transfers the file to the client outside of the WSGI process. I haven't personally used this in production - that's how I gather it works.

This would required some extra URL routes in MediaGoblin to handle the media files. Nginx config will also need media locations to be marked "internal" only.

One downside is we'll need a workaround for local development where Nginx is not available.

Given there's a bit of work here, I'll change the milestone to 0.12.0. I don't think we should rush this out.

(We should also be stripping the original filenames and replacing them with a non-sequential identifier, but that's another story and is still not enough for private mode I think.)

[Olivier Mehani]

Hey Ben,

Yeah, the availability of the files at their canonical URL is not great, even though one would have to guess both the sequence _AND_ the filename.

X-Sendfile sounds like a promising way to do it. Reading the NGINX doc, there is also support for it in lighthttpd and Apache [0], so it's good we're not prescribing too much here.

I'd just implement it as a completely separate feature orthogonal to private mode, though, and this should allow disabling it completely in dev: either send the file, or just add the X-Sendfile header if configured to do so.

The next bit of feature once that is implemented would be sharing specific content to unlogged users. I think X-Sendfile could be used in the same way, but we'd need to have some management of the shared URLs. At the moment, I just share the direct URLs to the files, but it's clearly a bug, not a feature (;

[0] ​https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/

[Fernando Gutierrez]

We could also use the authentication subrequest feature of nginx ​https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-subrequest-authentication/

Mediagoblin could expose a /auth url that nginx could check before allowing access to media files.

I implemented something based on that to mitigate scraper bots, it needs a lot of cleanup and it is not integrated to Mediagoblin but if I have time I could work on it.

[Ben Sturmfels]

See also #5351 - duplicate.