[hunchentoot-devel] A simple way to handle logins?
Graham Fawcett
graham.fawcett at gmail.com
Thu Nov 23 02:44:45 UTC 2006
On 11/22/06, Vamsee Kanakala <vamlists at gmail.com> wrote:
> Hi,
>
> Currently I'm using a simple method to handle logins in Hunchentoot -
> set the user object when the user logs in, and check for it at the
> beginning of a function whichever needs to have the credentials, or
> redirect to login page.
>
> However, most of my functions would require the login-check method to be
> run before they display the page. I'm guessing there should be a way to
> define a handler which takes all the requests, runs login function and
> then sends the request to the appropriate handler. Perhaps I should read
> the documentation more thoroughly, though I'd appreciate any tips which
> would make it easier.
If possible, arrange your dispatchers so that public
(anonymous-access) dispatchers are at the start of the dispatch table,
and restricted dispatchers appear near the end. Then, you can
introduce a "dummy dispatcher" between the two groups, that performs
the login-check and the redirection to your login page if needed.
For example:
(defun ensure-login (request)
"A dummy dispatcher that prevents non-logged-in users from passing."
;; assuming you're using sessions...
(and (not-logged-in-p (start-session))
#'(lambda () (redirect "/login"))))
(defun not-logged-in-p (session) ...)
(setq *dispatch-table*
(list (create-prefix-dispatcher "/public" 'public-handler)
(create-prefix-dispatcher "/login" 'login-handler)
#'ensure-login
(create-prefix-dispatcher "/admin" 'admin-handler)
;; etc.
#'default-dispatcher))
The trick is to have ENSURE-LOGIN return NIL if the user is
logged in. You may still want fine-grained access control in some
of your handlers, but this approach handles the general case
nicely.
Graham
More information about the Tbnl-devel
mailing list