[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