in an earlier message, you defended the existence of a
separate permission "Access Session Data" (in the
CoreSessionTracking proposal) by the following
There may be (authenticated) users with
(TTF?) scripting rights that should be prevented
to screen session data (by withdrawing
the "Access Session Data" permission from
This will only be effective, when not all users automatically
have the "Anonymous" role.
There was a discussion about the "Anonymous" role some
months ago in the list:
* The (outdated) Content Manager Guide mentions that
any user has the role "Anonymous".
* A role "Anonymous" with the meaning
"not authenticated" will make management for
sites with authenticated, non-manager users
more difficult, as those users should have most
rights of "Anonymous".
Only in exceptional cases, e.g. for session data,
they will have less priviledges.
If the meaning of "Anonymous" changes in this
direction, then this role should be explicitely
assignable to users in the "Change User" view
to avoid such difficulties.
I would be much in favour of a solution that does not
entail new permissions. This would be possible,
if session id management and access to session data
would be melted together.
In the current proposal, both are separate modules linked
by the application:
the application obtains a session id from the id manager
and then accesses the session data, usually with the id,
but in principle with anything it likes, e.g. a stolen session id.
It seems that the new permissions should help to control
If the session id becomes an implicit (not DTML-forgable)
parameter for session data access, then the session
data need not to be protected by new permissions.
However, I agree with you, that even making session id management
implicit, will not provide strict security.
Why am I against new permissions?
This has partly to do with the current Zope permission management.
As soon as you have more than a few products installed and
created a few additional roles, permission management becomes
a nightmare: it is very difficult to keep the overview
with the current unstructured, non-batched permission setting
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -