> > 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?
> 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-if "(stack and stack[:6]!='manage')">
(assuming the next component of the path is the session id,
remove it from the traversal path)
(somehow make sure that the session_id is valid and revive the
session object. With SQLSession, may be done by
(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)
What this does is translate a url of the form
to http://server.com/real/path for resource-search purposes, while
making sure that all calls to absolute_url() return urls of the form
http://server.com/123456/... . 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.
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -