On Thu, 4 Nov 2004 16:43:19 -0700, Thomas Rampelberg <pyronicide@gmail.com> wrote:
Is there a way to keep users from being able to see any of the management pages? For example, return a 404 error if someone tries to go to http://zopesite/manage or http://zopesite/object/manage.
This would also apply to yourself wanting to access the ZMI, are you sure you want to do this?
Idealy, I'd like to be able to produce 404 errors for everyone trying to access manage from an external ip. Would it be possible to edit the code for the manage page and insert some ZPT / DTML to redirect for external ips?
Unless they can authenticate they will not see the ZMI ... they'd need to login as a user with the "Manager" role. (or be granted this access through a script using a manager proxy role executing arbitary code because it trusted a form field passed to it by a user *g*...)
I am using LDAPUserFolder to give users an Authenticated role (not Manager), and if you type 'manage' after any URL (http://zopesite/object/manage), there is a management pane shown for them. With the right security settings, they are unable to do anything other than see the tree structure in the directory (the user folder and such) but for asthetic issues, I was wondering if there was a way to completely disable this.
In a similar vein, how would you go about keeping users from executing python scripts or external methods by just typing in the path to that object (http://zopesite/pythonscript) yet still let the pages that use those methods to access them?
Protect them via the "Security" TAB (in ZMI) then only users with the required priviledges can render, inspect and/or modify the so restrained Z-Object.
I understand what you are saying, but I'm not sure exactly how to implement this. I have tried restricting privileges on the external methods that I am using, but when I give the method enough permissions to be able to be called from a page on my site, anyone who has authenticated (base authenticated role) is able to then execute that method from a URL. I might be missing something in the paradigm here ....
Hi, Am Fr, den 05.11.2004 schrieb Thomas Rampelberg um 1:14:
On Thu, 4 Nov 2004 16:43:19 -0700, Thomas Rampelberg <pyronicide@gmail.com> wrote:
Is there a way to keep users from being able to see any of the management pages? For example, return a 404 error if someone tries to go to http://zopesite/manage or http://zopesite/object/manage.
This would also apply to yourself wanting to access the ZMI, are you sure you want to do this?
Idealy, I'd like to be able to produce 404 errors for everyone trying to access manage from an external ip.
Whats wrong with 401 here? Either case would keep anyone away.
Would it be possible to edit the code for the manage page and insert some ZPT / DTML to redirect for external ips?
No need. If you really want, modify one of the user folders challenge.
Unless they can authenticate they will not see the ZMI ... they'd need to login as a user with the "Manager" role. (or be granted this access through a script using a manager proxy role executing arbitary code because it trusted a form field passed to it by a user *g*...)
I am using LDAPUserFolder to give users an Authenticated role (not Manager), and if you type 'manage' after any URL (http://zopesite/object/manage), there is a management pane shown for them. With the right security settings, they are unable to do anything other than see the tree structure in the directory (the user folder and such) but for asthetic issues, I was wondering if there was a way to completely disable this.
So just disable access to management screensfor these roles. The security tab is made for this.
In a similar vein, how would you go about keeping users from executing python scripts or external methods by just typing in the path to that object (http://zopesite/pythonscript) yet still let the pages that use those methods to access them?
Protect them via the "Security" TAB (in ZMI) then only users with the required priviledges can render, inspect and/or modify the so restrained Z-Object.
I understand what you are saying, but I'm not sure exactly how to implement this. I have tried restricting privileges on the external methods that I am using, but when I give the method enough permissions to be able to be called from a page on my site, anyone who has authenticated (base authenticated role) is able to then execute that method from a URL.
You can set proxy roles on the calling objects. And if designed correctly the users cant do much other with the scripts anyway. Regards Tino
participants (2)
-
Thomas Rampelberg -
Tino Wildenhain