I've posted what I have so far here:
http://github.com/pelle/clauth
The concept is that it should be possible to decorate your app with
user authentication. There are 2 components of this that should be
extendable.
1. User repositories so you can connect it to any database. There is
currently implemented a memory store (clauth.users.memory), but it
should be easy to implement it to any database. I am planning on
writing a prevalent store, a neo4j store and a couchdb store. Please
fork and submit others if interested.
2. Authentication strategies. This is not yet implemented but my idea
is that there will be several pluggable strategies such as:
* http session login (implemented)
* basic authentication
* OAuth (next on my list)
* Facebook
* OpenID
Please bear in mind I'm writing this to teach myself clojure, so
please do let me know if I can do something better. I am very open to
suggestions.
This is also not yet complete, there are a couple of small bugs I need
to work out that more than likely have a lot todo with my newbie
Clojure programmer status.
2 particular issues that are almost due to my cluelessness which I
would love help on are:
The first issue is more compojure related. I can not get my user to
logout again. I have a function process-logout which looks like this:
(defn process-logout
"logout user by removing login attribute on session"
[]
(session-dissoc :login))
This is called within a compojure app like this:
(GET "/logout"
(do
(process-logout)
(redirect-to "/")))
Going to logout does the redirect, but never removes login from the
session. Any ideas?
Second issue isn't really compojure related, but I'm posting it anyway
in case anyone here should know the answer. I am using leiningen and I
can't get "lein test" to work. It just gives me a huge stacktrace with
this at the top:
[null] java.lang.Exception: No such var: clojure.test/successful?
(NO_SOURCE_FILE:1)
[null] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:172)
[null] at org.apache.tools.ant.taskdefs.Java.run(Java.java:705)
[null] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:177)
[null] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:83)
My first guess was that it doesn't have clojure-contrib in the
classpath, but it is in my project.clj file as a dependency.
Regards
P
--
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog
I have only had a very short look at your code, but I'm looking into
this kind of thing at the moment, so thanks for posting this. If it
turns out to be useful to me I'd be happy to fix/improve/critique
stuff that I think needs to be fixed/whatever.
[...]
> Please bear in mind I'm writing this to teach myself clojure, so
> please do let me know if I can do something better. I am very open to
> suggestions.
>
> This is also not yet complete, there are a couple of small bugs I need
> to work out that more than likely have a lot todo with my newbie
> Clojure programmer status.
One of the main "problems" I see with your API is that it seems to
rely- as much of compojure does - on dynamic/special variables. I'm
not necessarily against the use of dynamic variables, but there are
two big problems with them:
1. dynamic vars "hide" all kinds of conditions in a non-obvious
context, and they destroy referential integrity.
2. (and this is related to 1) in the current clojure implementation,
you can't have multiple values for a dynamic var in the same thread.
This becomes a serious obstacle when you run out of interpreter
threads.
I would like to see at least some kind of "low-level" version of the
API that allows passing around "manually" all the context that's
actually needed, that don't rely on things like *current-user* etc.
What do you mean by "dynamic/special variables"? Compojure doesn't
really use any thread-local var bindings, if that's what you mean.
- James
Yes it does. See *params*
Yes... but that's the only one I can think of (aside from the legacy
validation library), and its entirely optional. You can pass
parameters explicitly to form fields, instead of using with-params.
e.g.
(with-params params
(text-field :foo)
(text-field :bar))
Is the same as:
[(text-field :foo (params :foo))
(text-field :bar (params :bar))]
I dislike using unconstrained dynamic vars, but using a with-blah form
to assign a thread-local var within a specific scope seems idiomatic
Clojure to me. The same principle is used for clojure.core/with-out-
str.
- James
May I suggest utilizing the clj-oauth for your "OAuth (next on my
list)" todo item instead of writing one from scratch:
http://github.com/mattrepl/clj-oauth
Regards,
-Alen
> --http://agree2.com- Reach Agreement!http://extraeagle.com- Solutions for the electronic Extra Legal worldhttp://stakeventures.com- Bootstrapping blog
P
> --
>
> You received this message because you are subscribed to the Google Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en.
If you are familiar with my work on the oauth gem and oauth rails
plugin in Ruby, clj-oauth would be equivalent to the oauth gem and the
integration with clauth would be the equivalent of the oauth rails
plugin.
-P
> --
>
> You received this message because you are subscribed to the Google Groups "Compojure" group.
> To post to this group, send email to comp...@googlegroups.com.
> To unsubscribe from this group, send email to compojure+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/compojure?hl=en.
>
>
>
--
I'm the author of clj-oauth, it does only support the consumer role.
Please let me know if you add provider support, my thought was to add
a oauth.provider or oauth.server namespace to contain the
functionality. I'll make sure to pull any improvements made.
Take care,
Matt
> >> --http://agree2.com-Reach Agreement!http://extraeagle.com-Solutions for the electronic Extra Legal worldhttp://stakeventures.com-Bootstrapping blog
The names consumers and providers have caused lots of confusion so the
OAuth community is now trying to push client and server as the more
logical names.
I'll try to start work on that this week.
P