CLSQl middleware and the environment.

[Karl Heinrichmeyer]

Hi,

While working on the postmodern middleware I noticed that is would be useful to establish some naming conventions for the clack environment that is passed between the middlewares. This makes it easier to write middlewares that build upon each other.

One example: The new postmodern middleware stores the database connection in the environment to allow database connections to multiple databases. It would be nice if the clsql middleware would behave similar (I can change it if you like the idea) and if it uses a similar pattern for naming the environment key.

Another example is a role managing middleware that I wrote (I'll send a pull request if there is interest and if it proves to be useful in my project). The middleware loads the roles a user possesses and stores them in the environment. If they get changed during the request then the changed roles will be stored back. The roles are represented by a list of keywords that act like a set. There is also a new annotation for caveman that enables something like

@url GET "/test"
@require-roles (and :user :admin) "/access-denied"
(defun test (params)
   ...)

Which redirects the request to /access-denied if the user does not satisfy the role requirements (you can use 'and' and 'or' in your role constraint).

At the moment I use this middleware together with the basic auth middleware and rely on the :remote-user key in the environment. If there were a naming convention that governs how to store the user name into the environment then you could use this middleware together with for example the session middleware or with a custom authentication middleware in case you don't want to use HTTP Authentication.

Any ideas regarding this issue?

Best regards,

Karl

[Eitarow Fukamachi]

Hi, Karl.

Sorry for the late reply and thanks for the proposal.

I'm feeling it is hard to make the only rule how to name for all middlewares, and I'm afraid some middlewares which depends on each other tightly could break "Be loosely coupled", the thought of Clack, but anyway, we can start trying about the two cases.

In CLSQL case, I don't get what kind of middlewares can be written, but it may be good for newbie they provides similar interface.

(FYI, if you're thinking to run your application on the both of CLSQL and Postmodern, you can also use CL-DBI and Clack.Middleware.DBI.)

> @url GET "/test"

> @require-roles (and :user :admin) "/access-denied"

> (defun test (params)

>    ...)

This looks neat.

I was wondering what to implement something like access control on Caveman, so this example is really interesting for me.

OMHO, all auth middlewares put the user name into :remote-user for the time being, and let's start considering again when we bumped into any problems. (Or already you had?)

Regards,

Eitarow Fukamachi

--
--
深町英太郎 (Eitarow Fukamachi)

[Karl Heinrichmeyer]

Hi Eitarow,

Am Freitag, 13. Juli 2012 05:51:19 UTC+2 schrieb fukamachi:

Hi, Karl.

Sorry for the late reply and thanks for the proposal.

I'm feeling it is hard to make the only rule how to name for all middlewares, and I'm afraid some middlewares which depends on each other tightly could break "Be loosely coupled", the thought of Clack, but anyway, we can start trying about the two cases.

 

I see what you mean with the "loose coupling", that's a valid point. On the other hand you sometimes need the dependency (one example would be the auth middleware that looks up user names/passwords in a database). The question is how to handle this dependencies transparently. One way would be to establish a naming convention, but as you said, this might be brittle.
Another idea is to parameterize the dependent middlewares with the names of the env entries or accessors functions. This would be more flexible but also more work in the code.
Do you have an idea how to solve such dependencies without tight coupling?

To keep clack consistent in the way the middlewares behave still would make life a lot easier. The problem is how to manage this "style issues"? We could extract the conventional behavior into superclasses (for example a database-middleware class that handles storage of the database into the env or a authentication-middleware class that takes a user and stores it into :remote-user) but I'm not sure how well this will work out.

Maybe the solution isn't to nail down the behavior of specific middlewarers but to extract and clarify some 'concepts' (for example the concept of middlewares that work with the user name or middlewares that establish some kind of connection [database or tcp or what ever]) and make them behave similar. Any Ideas on your side? Or do you think this isn't that big a problem?
 

In CLSQL case, I don't get what kind of middlewares can be written, but it may be good for newbie they provides similar interface.

(FYI, if you're thinking to run your application on the both of CLSQL and Postmodern, you can also use CL-DBI and Clack.Middleware.DBI.)

> @url GET "/test"

> @require-roles (and :user :admin) "/access-denied"

> (defun test (params)

>    ...)

This looks neat.

I was wondering what to implement something like access control on Caveman, so this example is really interesting for me.

I'll try to hurry integrating the code into caveman :)
 

OMHO, all auth middlewares put the user name into :remote-user for the time being, and let's start considering again when we bumped into any problems. (Or already you had?)

 

No, there was no problem. But fixing this possible issue, even if it is only by writing some lines in the tutorial or at a good visible place in the documentation, would prevent this problem. And it is much easier than changing the behavior afterwards which may cost backwards compatibility. 

Regards,

Eitarow Fukamachi