Re: AW: Problems with jcNTUserFolder-0.0.4
a.wacknitz@francotyp.com wrote:
If a subfolder has its own NT user folder, a user, given another role within this subfolder, is forced to authenticate again and this authentication always fails. the roles given to the user in the sub-folder *replace* the roles defined in higher folders, due to the way user folders work. the user in the subfolder must have the same role as in higher folders (so he can traverse the higher folders), plus any new roles in the subfolder. This ist what I have done. But it does'nt work at all. What I want to have is the following: I have serveral users that should only see the root folder (/). All users have the role 'Benutzer' (german for user). Some users should be able to change the contents of subfolders. Therefore I have added an additional NT user folder in such subfolders. The users that should be able to change the contents are added within these NT user folders and have additional roles, such as 'administrator'. At the moment the roles of all other users are acquainted from the parent folders. But this doesn't work at all. Every user that has a new role in a subfolder is prompted for his name and password again. And whatever is entered, the authentifation fails. Only users with acquainted roles can see these subfolders. I tested with a standard user folder, and this does not work either. this may be a bug?? Let's sum up: the Anonymous role is revoked all rights from the top level, and a role 'User' is created with the same rights as Anonymous. In the toplevel, a user 'u' is given the role 'User'. In a sub folder, another user folder is created, and 'u' is given the roles 'Manager' and 'User'. When 'u' try to browse the subfolder, an exception is raised because he is unthorized to access standard_html_header (???) Note that if standard_html_header is copied in the subfolder, the error goes away.
This is very bizarre. Should I post this to the collector?
I should mention that I revoked all rights for anonymous users. So everybody must log in to use the site. I think that all "public" content must be viewable by the anonymous user, even if it desirable that all users have to authenticate (ie, the "public" is well known) the problem is that authentication is not required for anonymous content. I just written a product, jcForceAuth, which force users to authenticate, even for anonymous content. you can see it at http://www.zope.org/Members/jephte/jcForceAuth This is a product, and it is installed the usual way. It "patches" ZPublisher on the fly to raise unauthorized if no authentication headers are found.
I hope this helps BTW, any comments are welcome regards, jephte clain minf7@educ.univ-reunion.fr
On Sat, 1 Apr 2000, Jephte CLAIN wrote:
I tested with a standard user folder, and this does not work either. this may be a bug?? Let's sum up: the Anonymous role is revoked all rights from the top level, and a role 'User' is created with the same rights as Anonymous. In the toplevel, a user 'u' is given the role 'User'. In a sub folder, another user folder is created, and 'u' is given the roles 'Manager' and 'User'. When 'u' try to browse the subfolder, an exception is raised because he is unthorized to access standard_html_header (???) Note that if standard_html_header is copied in the subfolder, the error goes away.
This is very bizarre. Should I post this to the collector?
It looks like this is the way it is currently supposed to work. Even though the users have the same name, they are not the same user object. When you log into the subfolder, you are logged in as subfolder/acl_users/u. This user has no rights outside of subfolder, and none can be granted. So when you try to access subfolder/index_html, you are logged in as subfolder/acl_users/u. Zope then tries to render index_html as this user. When index_html tries to execute the <dtml-var standard_html_header> tag, it will fail since the user we are attached as has no rights outside of the subfolder tree. And of course, if you point your browser to /standard_html_header, you will be able to access it as you will be logging in as /acl_users/u which does have the required rights. One method of solving the originally posted problem is to have only once acl_users folder at the root. The users who need higher rights in the subfolders can be granted these rights by using local roles. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen
Stuart 'Zen' Bishop wrote:
On Sat, 1 Apr 2000, Jephte CLAIN wrote:
I tested with a standard user folder, and this does not work either. this may be a bug?? Let's sum up: the Anonymous role is revoked all rights from the top level, and a role 'User' is created with the same rights as Anonymous. In the toplevel, a user 'u' is given the role 'User'. In a sub folder, another user folder is created, and 'u' is given the roles 'Manager' and 'User'. When 'u' try to browse the subfolder, an exception is raised because he is unthorized to access standard_html_header (???) Note that if standard_html_header is copied in the subfolder, the error goes away. This is very bizarre. Should I post this to the collector? It looks like this is the way it is currently supposed to work. Even though the users have the same name, they are not the same user object. When you log into the subfolder, you are logged in as subfolder/acl_users/u. This user has no rights outside of subfolder, and none can be granted.
So when you try to access subfolder/index_html, you are logged in as subfolder/acl_users/u. Zope then tries to render index_html as this user. When index_html tries to execute the <dtml-var standard_html_header> tag, it will fail since the user we are attached as has no rights outside of the subfolder tree.
And of course, if you point your browser to /standard_html_header, you will be able to access it as you will be logging in as /acl_users/u which does have the required rights.
One method of solving the originally posted problem is to have only once acl_users folder at the root. The users who need higher rights in the subfolders can be granted these rights by using local roles.
If I understand well, it is not possible, not using local roles, to acquire non anonymous content above a user folder in the hierarchy, right? I wonder if this is the reason why local roles were introduced. have a nice day, jephte clain minf7@educ.univ-reunion.fr
participants (2)
-
Jephte CLAIN -
Stuart 'Zen' Bishop