Dieter writes:

>  > If I can't safely assume any of the above, would I be better off using a
>  > session product to track a user after log in so I can determine their roles
>  > from an unprotected document?  Any other ways?
> If the session product uses cookies, you will have a situation
> similar to cookie based authentication. Otherwise, you
> will need to shift the session id often between query string
> and hidden variable which is a bit tedious.

One relatively less tedious way to do this would be to put the session
id in the URL rather than in forms; you can do this by using an access
rule along the lines of:

<dtml-let stack="REQUEST['TraversalRequestNameStack']">
 <dtml-if "(stack and stack[0][:6]!='manage')">
  (assuming the next component of the path is the session id,
   remove it from the traversal path)
  <dtml-call "REQUEST.set('session_id',stack.pop())">
  (somehow make sure that the session_id is valid and revive the
   session object. With SQLSession, may be done by
  <dtml-call "Session(session_id)">
  (path in the next line is supposed to be replaced by something
   which, preferebly dynamically, retrieves the path traversed up
   to this point. This is needed so the session id shows up in
   URLs generated down the tree)
  <dtml-call "REQUEST.setVirtualRoot(path+'/'+session_id)

What this does is translate a url of the form
to for resource-search purposes, while
making sure that all calls to absolute_url() return urls of the form . This means that as long as you rely
on absolute_url rather than relative links, you're essentially done.

This ignores session initialization first time, but I hope the
general idea of how to do this is enough. I don't have a live
example at my fingertips, but something a lot like this was done
here some time ago.

Have fun,

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to