I'm designing a website with a lot of functionality that I don't want to expose directly to site visitors. Since I lack the Zope terminology for this, here's an example of what I mean: I have a Python script named "doSecretStuff" in the root of the site's folder. Now, I want to be able to call that script from DTML documents and other Python scripts, but I *don't* want end users to be able to visit http://www.example.com/doSecretStuff to execute it directly. Can Zope's security model handle this? If so, what would this be called (I'm happy to research it myself if I can find a name for it)? Right now my site's security is by obscurity and I'm not really satisfied with that. -- Kirk Strauser The Day Companies
From: "Kirk Strauser" <kirk@daycos.com>
I have a Python script named "doSecretStuff" in the root of the site's folder. Now, I want to be able to call that script from DTML documents and other Python scripts, but I *don't* want end users to be able to visit http://www.example.com/doSecretStuff to execute it directly.
Can Zope's security model handle this?
Well, you then have to give the dtml documents and python scipts that should call this script proxy roles so that they have roles and permissions that the users themselves doesn't have.
On Tuesday 2004-02-03 10:44 am, Lennart Regebro wrote:
Well, you then have to give the dtml documents and python scipts that should call this script proxy roles so that they have roles and permissions that the users themselves doesn't have.
But suppose that I have 20-30 of these objects (think database connections, encryption functions, etc.) that are called from almost every single object in the site's folder. Do I really have to give proxy files to each of those individually? If so, then so be it, but it seems like there has to be another way. -- Kirk Strauser The Day Companies
From: "Kirk Strauser" <kirk@daycos.com>
But suppose that I have 20-30 of these objects (think database connections, encryption functions, etc.) that are called from almost every single object in the site's folder.
Then you should develop a proper Zope product to handle all that and let it deal with the security.
On Wednesday 2004-02-04 09:02 am, Lennart Regebro wrote:
Then you should develop a proper Zope product to handle all that and let it deal with the security.
That seems like massive overkill to a problem that other people have to have solved already. I mean, is it really standard procedure to allow full access to database objects? -- Kirk Strauser The Day Companies
From: "Kirk Strauser" <kirk@daycos.com>
Then you should develop a proper Zope product to handle all that and let it deal with the security.
That seems like massive overkill to a problem that other people have to have solved already.
Creating a product is rarely overkill except for the simplest of applications, and definitely not overkill if you have 20-30 objects that you need proxy access too. In fact, it is usually much simpler to make a product than to do something even remoly complicated through the ZMI.
I mean, is it really standard procedure to allow full access to database objects?
No, standard procedure is to make a product. :-) Really, it's not that hard.
On Wednesday 2004-02-04 09:50 am, Lennart Regebro wrote:
Creating a product is rarely overkill except for the simplest of applications, and definitely not overkill if you have 20-30 objects that you need proxy access too. In fact, it is usually much simpler to make a product than to do something even remoly complicated through the ZMI.
OK, then, maybe you could punt me in the right direction. As an example, I have several database connections that are accessed from many non-related objects. That is, a particular database may have information on user accounts, zip codes, and inventory - not things that are logically related to each other. How would you factor these so that those objects all have access to the same database, and that database isn't globally accessible to anyone who guesses its name? How could I use products to allow this? -- Kirk Strauser The Day Companies
From: "Kirk Strauser" <kirk@daycos.com>
OK, then, maybe you could punt me in the right direction. As an example, I have several database connections that are accessed from many non-related objects. That is, a particular database may have information on user accounts, zip codes, and inventory - not things that are logically related to each other. How would you factor these so that those objects all have access to the same database, and that database isn't globally accessible to anyone who guesses its name? How could I use products to allow this?
Well, it's hard to say from over here, but I would probably create an object that maintains the database connection as a subobject that is not directly accessible. Then I would on that object create methods that do what you want the methods to do, and set permissions on the objects as you want them. This would mean that users with the right permissions can access the methods, but nobody can directly access the database connection. If you need flexibility in what database connection should be used, then you could let the object be folderish, and create the database connection inside it. You could set up that connection to only allow managers to access it. The python code on the hard disk would still be able to access it. //Lennart
participants (2)
-
Kirk Strauser -
Lennart Regebro