Hi All;

The subject line is the Short Version of the question, and I am sorry
if it a real dumb one, but I would appreciate being pointed in the
right direction.

I have a webapp using one of the many versions of "login-maybe"
authentication logic that has crossed this list.  My custom Weblocks
widget render-widget-body method spits out HTML with lots of :img icon
URLs.

The set of such icons/images is large, and the icons: are going to be
requested kind of a lot; are NOT part of the webapp proper; thus do
NOT live in pub/images; are independently version-controlled; and are
part of a larger collection of other types of files (which may also
need to be served later, WebDAV-style).  I am currently successfully
using a Hunchentoot easy-handler to serve them (although I have not
tried to check any authentication-related session vars).

To recap: I would like to serve up the icons only to authenticated
users.  I presume I would be smart to do this in browser-cache and
proxy-cache ways so that image requests can get served out of some
sort of memcache/squid server, transparently to weblocks and the user.
Finally, I would like to package the image serving along with the
custom widgetry in a weblocks "contrib" friendly way (and the
Hunchentoot easy-handler doesn't seem that pretty in a modularity-sort
of way).

Which is the smart plan?

Plan (1): add checking of the authentication logic to the Hunchentoot
easy-handler (whose :uri does not share the most-significant webapp
token with the webapp).

Plan (2): push a Hunchentoot create-static-file-dispatcher-and-handler
onto the *dispatch-table* and try to figure out how to get at the
authentication session info from there

Plan (3): leave it as-is and admit defeat (maybe rationalizing this by
using Hunchentoot's in-memory image serving in a quest for speed)...

Plan (4): something else?????  URL rewriting to derive
authenticated-p?

Thanks in advance,

-jm

-- 
--- John Morrison
--- [email protected]

-- 
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en.

Reply via email to