people structuring
Why do you have containers for the different types of persons?
A more natural thing would be to have just one container and use catalog searches (or "topic"s) to determine the subsets as necessary.
My thoughts were that people are spread across our organisiation in different groupings, and may belong to more than one grouping. Other 'objects' may contain these groups eg: a unit object has one or more lecturers, as well as many students. A committee object has members etc. What I wanted was to find a way to keep to the object oriented spirit of zope/python and to be able to express things like funCommittee.members.joe.shoeSize and mathsClass.lecturers.joe.shoeSize where joe's shoe size is not a property of 'joe the lecturer' or 'joe the committee member' but of 'joe the person'. And wouldn't it be nice if for some reason joe's feet swelled during lecturing and had a different size, and mathsClass.lecturers.joe.shoeSize could return the correct shoeSize in this context! (Something similar to aquisition but not quite as Units may not be within the Person structure). Maybe I want a "Link Object" product where 'joe the lecturer' is just a link to 'joe the person' but with aquisition rules following the link heirarchy. The above is probably mostly fantasy, so I'll investigate doing it with catalogues but don't know if it will be as pretty. Thanks, Roman.
Hi All - Been lurking on the list for a while, first post. My question is this: I'd like to have some sort of protection in the for the 'top' level accounts that could really munge up the site (we're using Plone over Zope) if somebody got ahold of them. I know the passwords are stored encrypted, but for all I've been able to find, they're still transmitted in plain text, correct? So, we had two ideas: First, is it possible to limit access of certain accounts based on an IP address? We should only ever be logging in as admins from our internal machines, so any external non-us IP would be automatically rejected. Second, we had thought about setting up Zope & Apache to use SSL, but that seemed like a bit of overkill for a relatively simple desire. Should I just go the SSL route, or is there a more obvious solution we're overlooking to protecting our more privileged accounts? Thanks, -Jake
Jake Latham wrote at 2003-9-23 09:32 -0600:
... So, we had two ideas: First, is it possible to limit access of certain accounts based on an IP address? We should only ever be logging in as admins from our internal machines, so any external non-us IP would be automatically rejected.
Zope allows you to restrict logins based on IP/domain information. Note, however, that IP information can be forged without too much difficulties (--> maskerading).
Second, we had thought about setting up Zope & Apache to use SSL, but that seemed like a bit of overkill for a relatively simple desire.
Should I just go the SSL route, or is there a more obvious solution we're overlooking to protecting our more privileged accounts?
"https" will slow your site down. If this is not a problem, go this way. I plan to implement a post-authentication-hook for Zope. It will try to acquire an object "post_authentication_hook" and call it, if successful. The object (e.g. a Python Script) can then perform arbitrary checks, e.g. ensure that the current request came via "https" or is not proxied via Apache when the published object require a "Manager" role. Up to now, it is just a plan; there is no time table yet... Dieter
Jake Latham wrote:
So, we had two ideas: First, is it possible to limit access of certain accounts based on an IP address? We should only ever be logging in as admins from our internal machines, so any external non-us IP would be automatically rejected.
Yeah, use the 'domains' box in the acl_users folder. Bear in mind that will slow your Zope down some...
Second, we had thought about setting up Zope & Apache to use SSL, but that seemed like a bit of overkill for a relatively simple desire.
It's a much securer way of doing it :-) Chris
Roman Bogoyev wrote at 2003-9-23 22:38 +0800:
... My thoughts were that people are spread across our organisiation in different groupings, and may belong to more than one grouping. Other 'objects' may contain these groups eg: a unit object has one or more lecturers, as well as many students. A committee object has members etc.
What I wanted was to find a way to keep to the object oriented spirit of zope/python and to be able to express things like
funCommittee.members.joe.shoeSize
and
mathsClass.lecturers.joe.shoeSize
You could do that but you will need advanced (and potentially dangerous) features (such as "__getattr__"). Only go this route when you are a proficient Python programmer.
where joe's shoe size is not a property of 'joe the lecturer' or 'joe the committee member' but of 'joe the person'. And wouldn't it be nice if for some reason joe's feet swelled during lecturing and had a different size, and mathsClass.lecturers.joe.shoeSize could return the correct shoeSize in this context!
Do you really need that? If so, expect your project to take 10 times as long as you had expected ;-) Always start as simple as possible. Do not go for nice features you do not really need. Dieter
My thoughts were that people are spread across our organisiation in different groupings, and may belong to more than one grouping. Other 'objects' may contain these groups eg: a unit object has one or more lecturers, as well as many students. A committee object has members etc. What I wanted was to find a way to keep to the object oriented spirit of zope/python and to be able to express things like
funCommittee.members.joe.shoeSize and mathsClass.lecturers.joe.shoeSize
where joe's shoe size is not a property of 'joe the lecturer' or 'joe the committee member' but of 'joe the person'. And wouldn't it be nice if for some reason joe's feet swelled during lecturing and had a different size, and mathsClass.lecturers.joe.shoeSize could return the correct shoeSize in this context! (Something similar to aquisition but not quite as Units may not be within the Person structure). Maybe I want a "Link Object" product where 'joe the lecturer' is just a link to 'joe the person' but with aquisition rules following the link heirarchy.
The above is probably mostly fantasy, so I'll investigate doing it with catalogues but don't know if it will be as pretty.
In Python products you can store references to existing objects, which would allow multiple locations for people, after a fashion. You might also want to look at something like mxmRelation, which allows many clever things in this sort of domain. There are also a host of "link-ish" products, like PortableHole, and others. (You might search past postings for portableHole to find comparables.) --jcc
participants (5)
-
Chris Withers -
Dieter Maurer -
J Cameron Cooper -
Jake Latham -
Roman Bogoyev