Clojurians Log v2

Thinking about it, I strongly agree with you that it should be middleware. However the dependency system poses a problem for that approach. I don't have a good idea that I like though.

@dominicm I think if it’s just the root of all deps that should work out pretty well in practice. On server boot we can set some flag that controls the behaviour of the middleware and makes it do something or nothing. But I haven’t thought that much about this either.

@bozhidar the root of all deps?

@dominicm The root of the middleware stack - every middleware would expect the auth middleware to be present.

Generally that’s not really needed - I guess we’re mostly concerned about securing eval-type operations.

That makes sense. But conflates authentication with authorization.

I guess the auth middleware could evaluate the request statically and determine whether it's safe.

Is it possible to add dependencies as a user, as opposed to an author of middleware. I think that would be important.

> That makes sense. But conflates authentication with authorization. Yep, that’s true. Anyways, that’s why I asked for more people to share some feedback - I certainly don’t know what’s the optimum course of action, but I feel that anything will be an improvement over no security at all. 🙂

So, if we make this middleware, the world needs to go out and decide whether it's middleware needs to depend on auth. Conditional on being able to extend the dependencies and authorization of an op as a user, that seems fine. Separating authentication and authorization seems like a good pre emptive strike, particularly for us as we would want to inspect responses for particular values and block them under certain conditions (e.g. Breakglass)

> So, if we make this middleware, the world needs to go out and decide whether it’s middleware needs to depend on auth.

That’s true, but the same applies for some very basic things even now - e.g. sessions.

One can argue they should always be present, but since they are middleware it’s up to middleware authors to decide how to leverage them.

> Separating authentication and authorization seems like a good pre emptive strike, particularly for us as we would want to inspect responses for particular values and block them under certain conditions (e.g. Breakglass)

Btw, what when you talk about authorization you’re mostly talking about making sure people don’t execute some insecure code, right? Because if we go with a simple authentication scheme with no permissions attached to it then there won’t be much to check for when it comes to authorization.

I would personally probably build something on a claim system that my authorization system would then check.

I don’t understand what you mean. Can you elaborate on this?

You get claims to certain functionality in production. Perhaps evaluations from a predefined set, or just refresh. That would encode into the token along with an expiration and a signature.