Re: [Zope3-dev] Important Heads Up: I'm making IResult private
Previously Chris McDonough wrote: On Dec 26, 2005, at 8:51 AM, Jim Fulton wrote: Even on a unix-based platform on which the file is removed before data are written to it? For this project, yes, given that the project owners believe their business model depends on no sensitive unencrypted data ever being written to persistent storage (even temporarily). Can you transfer the data through a unix domain socket or a pipe? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [FrontPage] Wiki is now cleaned or at least Christian does not work on it anymore.
Am Mittwoch, den 11.01.2006, 12:45 -0500 schrieb srichter: --removed: - div class=messageThe Zope 3 wiki is beeing tidied up. Please bear with any inconvenience while this happens./div Right. I got distracted and never went back. I still have to think about it and will get back to this. This might take some time, though. The current state is slightly improved from the one before. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: .xpt extension for explicit xml processing
On 1/12/06, Tonico Strasser [EMAIL PROTECTED] wrote: I found another situation where HTML mode helps the author to be backward (speak MSIE 6) compatible: In XML mode this snippet html xmlns=blah script/script /html ... . This would cause IE to display a blank page! The code that's been written so far handles this by generating script/script instead of script/. Some details of the XML mode clearly have to be adjusted to make browsers happy; that's a limitation of current browsers that we know we have to live with. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Mini-proposal: zope.app.authentication group events
Problem:
We want to perform actions when a user is added to a group, and
possibly when a user is removed from a group. There is no hook point
for this currently in the zope.app.authentication code.
Solution:
Fire events in the zope.app.authentication code when principals are
added and removed from groups.
88
from zope import interface
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal
was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
88
In terms of implementation, it looks like
zope.app.authentication.groupfolder.GroupFolder._addPrincipalToGroup
and
zope.app.authentication.groupfolder.GroupFolder._removePrincipalFromGrou
p are the methods that would fire the events.
Risks:
I am aware of None.
Thoughts?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Mini-proposal: new principal interface in zope.security for full closure of group membership
Primary problem: We frequently want to know the full closure of group membership. The groups attribute of zope.security.interfaces.IGroupAwarePrincipal is a list of groups to which the principal directly belongs. The full closure--including the groups to which the principal's groups belong, for instance--must be calculated by any piece of code that needs it. Secondary problem: The description of zope.security.interfaces.IGroupAwarePrincipal.groups does not sufficiently clarify that it is *not* a full closure. Consideration: zope.security.interfaces.IGroupAwarePrincipal has been around for awhile, and probably should not be materially changed (i.e., to redefine or add an attribute). Solution: 1) Clarify the zope.security.interfaces.IGroupAwarePrincipal.groups description: change from List of ids of groups the principal belongs to to List of ids of groups to which the principal directly belongs 2) Add an additional interface to zope.security.interfaces interface. class IGroupClosureAwarePrincipal(IGroupAwarePrincipal): allGroups = interface.Attribute( 'a readonly iterable of the full closure of the principal's groups.') 3) Make the principals in zope.app.authentication implement IGroupClosureAwarePrincipal. First cut of 'allGroups' would probably be to make it be a lazy property, returning a tuple of the full closure. Risks: Some might be unhappy that allGroups is not a hook point, but a convenience: that is, it will be a full closure, not an opportunity to be clever to redefine how group membership is calculated. Thoughts? Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mini-proposal: zope.app.authentication group events
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal
was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple
principals to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which the
principal was added')
principal_ids = interface.Attribute('an iterable of one or more
ids of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from which
the principal was removed')
principal_ids = interface.Attribute('an iterable of one or more
ids of principals removed')
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Twisted? We lost the username in the access.log
Jim Fulton wrote: This is fairly serious, but I don't want it to delay 3.2.1 final. I suggest we try to fix this the week after the final release. I'd like to shoot for getting a 3.2.1 release out around the end of January. I'd like to see a beta release around the middle of the month. Any word on this? This afternoon, I put together a hack that involves pushing the response's authuser in a header (zope.publisher.http.HTTPResponse.getHeaders) to twisted's response, then using that in the logger (twisted.web2.log.BaseCommonAccessLoggingObserver.emit). I am mainly interested in getting x-forwarded-for in the log (my machines are all behind pound, and 127.0.0.1 as ip address is pretty useless), but I found the XXX about user while I was spelunking there. -Jim Washington ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: full closure of group membership
Gary Poster wrote: Primary problem: We frequently want to know the full closure of group membership. The groups attribute of zope.security.interfaces.IGroupAwarePrincipal is a list of groups to which the principal directly belongs. The full closure--including the groups to which the principal's groups belong, for instance--must be calculated by any piece of code that needs it. Secondary problem: The description of zope.security.interfaces.IGroupAwarePrincipal.groups does not sufficiently clarify that it is *not* a full closure. Consideration: zope.security.interfaces.IGroupAwarePrincipal has been around for awhile, and probably should not be materially changed (i.e., to redefine or add an attribute). Solution: 1) Clarify the zope.security.interfaces.IGroupAwarePrincipal.groups description: change from List of ids of groups the principal belongs to to List of ids of groups to which the principal directly belongs 2) Add an additional interface to zope.security.interfaces interface. class IGroupClosureAwarePrincipal(IGroupAwarePrincipal): allGroups = interface.Attribute( 'a readonly iterable of the full closure of the principal's groups.') 3) Make the principals in zope.app.authentication implement IGroupClosureAwarePrincipal. First cut of 'allGroups' would probably be to make it be a lazy property, returning a tuple of the full closure. Risks: Some might be unhappy that allGroups is not a hook point, but a convenience: that is, it will be a full closure, not an opportunity to be clever to redefine how group membership is calculated. +1, a long time ago I suggested something similar because in the CPS framework of groups we need knowledge both of direct membership and transitive closure (we have a getGroups method that's the direct groups, and a getComputedGroups that's the transitive closure and is used for instance when we have groups of groups). I'm still not using the zope 3 principal framework but at some point I know I'll need it in zope 3 too :) Do you think your interfaces fit the need of computed groups? I'm not sure if the meaning of computed is clear but I can expand on that if it's not (for instance, it could be for the case where groups exist dynamically according to some computation on the prinicpal's properties). Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: zope.app.authentication group events
Gary Poster wrote:
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the principal was
added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the principal
was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple principals
to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which the
principal was added')
principal_ids = interface.Attribute('an iterable of one or more ids
of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from which the
principal was removed')
principal_ids = interface.Attribute('an iterable of one or more ids
of principals removed')
+1
But why the ids and not the objects themselves? Wouldn't it allow for
more flexibility?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: member-aware group interface
Gary Poster wrote:
Problem:
We need to be able to iterate over the members of a group, given a
group id. With the interfaces in zope.security, the only way to do
this is to iterate over all principals known to the system, check their
`groups` attribute, and if the group id is in the list then include
it. This is obviously problematic.
If we constrain ourselves to the pluggable authentication utility in
zope.app.authentication, we have some help, but it is pretty
inconvenient and conceivably problematic. The following (untested
sketch of a) approach is a good try for the common case, but won't
handle nested authentication utilities, and relies on an interface not
in an interfaces.py:
from zope import component
from zope.app.authentication import interfaces
import zope.app.authentication.groupfolder
group_id = 'foo'
auth = component.getUtility(interfaces.IPluggableAuthentication)
for name in auth.authenticatorPlugins:
plugin = component.queryUtility(
interfaces.IAuthenticatorPlugin, name, context=auth)
if zope.app.authentication.groupfolder.IGroupFolder.providedBy
(plugin):
try:
principals = plugin.getPrincipalsForGroup(group_id)
except KeyError:
pass
else:
break
else:
raise RuntimeError('Not Found')
Or something like that. As I said, this doesn't even handle some of
the more complex cases. Whew!
Solution:
Add a new interface to zope.security.interfaces:
class IMemberAwareGroup(IGroup):
members = interface.Attribute('an iterable of members of the group')
Then make the groups that the zope.app.authentication.groupfolder
plugin generates implement the new interface.
I think I'm for it, but in some cases even though groups may be able to
list all their members it may (if they're dynamically computed) turn out
to be a huge list. I guess in that case you could simply not advertise
that the group implements the interface.
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Mini-proposal: zope.app.authentication group events
On Jan 12, 2006, at 7:18 PM, Florent Guillaume wrote:
Gary Poster wrote:
On Jan 12, 2006, at 2:11 PM, Gary Poster wrote:
def IPrincipalAddedToGroup(interface.Inteface):
group = interface.Attribute('the group to which the
principal was added')
principal = interface.Attribute('the principal added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group = interface.Attribute('the group from which the
principal was removed')
principal = interface.Attribute('the principal removed')
Small change: clarify that these are ids, and allow multiple
principals to be specified.
def IPrincipalAddedToGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group to which
the principal was added')
principal_ids = interface.Attribute('an iterable of one or
more ids of principals added')
def IPrincipalRemovedFromGroup(interface.Inteface):
group_id = interface.Attribute('the id of the group from
which the principal was removed')
principal_ids = interface.Attribute('an iterable of one or
more ids of principals removed')
+1
Cool.
But why the ids and not the objects themselves?
It's driven by the interfaces and implementations around it . Since
Zope 3 generates the principal objects on the fly and actually only
manipulates principal ids for the persistent data, a number of
situations will not have objects already created for the pertinent
principals. Therefore this is just what falls out naturally.
Wouldn't it allow for more flexibility?
You can always convert an id to a principal (if it's a valid id) so I
don't think so.
Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mini-proposal: zope.app.authentication group events
On 1/12/06, Gary Poster [EMAIL PROTECTED] wrote: Problem: We want to perform actions when a user is added to a group, and possibly when a user is removed from a group. There is no hook point for this currently in the zope.app.authentication code. We certainly have use-cases for code that runs when a user is removed from a group. These events appear to be sufficient to me. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Principal Comparison and/or References
I found an issue with zope.app.undo's ZODBUndoManager wherein it only
could undo principal transactions if the principal in the request came
from the global principal registry. I tried patching our copy by
changing it to look up the principal of a transaction record from
zapi.principals() (gets the nearest IAuthentication utility).
When it tries to do the undo, it compares request.principal against
transaction['principal'] with identity comparison (' is '). That
doesn't work for pluggable auth principal folder based principals,
even if by my own assumptions and simple application setup they are
the same.
With all of the other principal / group mini-proposals going on, does
there need to be a way to strongly (if that's the right word) compare
a principal looked up from an id that came out of... well, somewhere
(a transaction log record, a string stored in the 'creators' dublin
core sequence, etc), or even against each other?
b3_1 = zapi.principals().getPrincipal('brcms.user.3')
b3_2 = zapi.principals().getPrincipal('brcms.user.3')
b3_1 is b3_2
False
b3_1 == b3_2
False
Comparing the id attribute works. Is it reasonable to assume that
zapi.principals().getPrincipal(request.principal.id) should return the
same principal as request.principal? And thus if
somerecord['creator_id'] == request.principal.id, that's considered a
good match?
--
Jeff Shell
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
