Background

OAuth requires an OAuth client to be registered with the server before any user can be asked to authorise the client to access a resource. This model makes sense for a centralised service provider, because authors of OAuth client applications only have to register their application once. For a decentralised service like MediaGoblin where there are many independent installations, the requirement to register a client becomes an obstacle.

Example

If I had a web application that allowed my users to link their MediaGoblin accounts in order to upload pictures through my web application to their MediaGoblin collections, I would have to register my application as a client on every MediaGoblin installation that I want to support. This doesn't scale.

Proposal

OAuth doesn't seem to be designed to cover this use case. Hence I propose to implement application-specific API tokens.

If a MediaGoblin user wanted to allow my web application to act on her behalf through the API, she would generate an API token for my web application and store the token with her account on my web application. My application can then use this token to perform uploads as the MediaGoblin user until the user decides to revoke the token.

A user could thus grant external applications limited access to their account by generating a new application-specific password. The application could authenticate against the MediaGoblin server by providing the user's username and the application-specific password.

(Something like that is used by Google when two factor authentication is enabled for Gmail and one needs a simple password to authenticate one's email client with the server.)

As I need something like that, I volunteer to work on implementing this if it turns out to be a good idea.

At the moment, running tests that don't use a full mediagoblin app are fast, ones that do are slow. Probably the reason for this is that we use 3 sqlite databases (one for celery, one for Kombu, one for mediagoblin itself).

I'm not sure whether the celery of kombu (which isn't used during tests anyway) databases would be affected by unit tests if we just switched them over to an in-memory database. It might be easy enough to just do those and they'd be just fine. I don't know.

MediaGoblin's db is a bit different because it needs to run the migration machinery to init the db. This means that things will be a bit tricky: Somehow we need to create a reference to the database *before* the MediaGoblin application spins up and connects it to the ORM. Then we need to pass that database connection (without the ORM initialized) to the migrations, then pass it into the MediaGoblin application, which must then connect the ORM to the database based on init.

Problem: we set up MediaGoblin's application wrapped in paste, so we don't have much control over this.

Here's an alternate solution, also evil, maybe even more so: MediaGoblin the application itself could contain a config option where it will, on init, run dbupdate from *within itself* if needed. (Note: that *could* be used in production environments also but I think it would more likely than not, especially if a person is both running MediaGoblin *and* celery, shoot us in the foot.)

I'm running MediaGoblin under the "mediagoblin" user and serve the files via Nginx/FCGI.

After converting uploaded videos, they have the wrong permissions (600 instead of 644). Images are fine.

Is there a way to define an umask and/or group for newly uploaded files?