Rob Browning

I could easily imagine the current approach might not be acceptable, but I'd be happy to make adjustments. Please see the commit message for additional explanation and rationale. I haven't...

Oh, and I'd imagine before we're finished, this should include some updates to the manual.

Oh, and in case it's not completely clear, the intention is that tools like lein might start specifying an auth-wrapper, i.e. (start-server ... :auth-wrapper (file-auth-wrapper (slurp "./nrepl-auth-token"))

> You'll have to elaborate on this a bit. We still have to authenticate every message regardless of the approach taken, so I'm a bit puzzled by this comment. I...

Bozhidar Batsov writes: > For this type of authentication yes. On the server side everything's > easy with respect to auth token and auth schemes. The real question is >...

> I guess you don't know that I'm the author of CIDER. wink That's why from the very beginning I've been thinking about this end-to-end. And I happen to be...

Regarding the middleware approach, were you just thinking that we might start with (defn default-auth-middlewares [] []) then maybe later change the default to something like: (defn default-auth-middlewares [] [#'nrepl.middleware.auth/require-nrepl-auth-token])...

Bozhidar Batsov writes: > Yeah, your suggestion makes sense to me. I'm assuming you plan to make > the auth-middlewares run before every other middleware, right? Yep, they'd always go...

Bozhidar Batsov writes: > Well, seems to me that'd be better - especially given the fact that i > called it `authentication` and you called it `authorization`. :D I >...

Bozhidar Batsov writes: > I think blanket authorization will be fine, so let's not overthink > this. After all any form of authorization is going to be infinitely > better...