Re: [Zope-dev] Questions about BasicUserFolder.authorize
Chris Withers [EMAIL PROTECTED] wrote:
AccessControl.User.BasicUserFolder defines:
def authorize(self, user, accessed, container, name, value, roles):
what is 'roles' in this context?
I'm working on a new release of SUF. I'd like to provide a scriptable method
which can
decide what roles a user has at a given location.
Ideally this would look something like:
roles_def= {
'/folder/object': {'chris':['Manager'],
'fred':['Anonymous']}
}
def getUserDetails(self,name,object):
return {
'password':'apassword',
'roles':roles_def[object.absolute_url()][name]
}
Would 'authorize' be the correct place to plug this in?
No, it wouldn't.
You'd have to modify the places where roles are computed for a given
location: 'getRolesInContext' and 'allowed'. This is not completely
factored out for efficiency reasons.
Basically, these are the two places that check __ac_local_roles__, going
up the hierarchy.
Florent
--
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bug Day for June?
Brian Lloyd [EMAIL PROTECTED] wrote: Are we having a Bug Day on Friday? I'd prefer if we could have Bug Days on Thursdays instead of Fridays. Friday means I have to stay late at work when the weekend has already started and everybody else is at the pub/café/parties :-) Same thing for all of us Europeans I guess. How about _next_ Thursday (the 20th)? Things are pretty hectic here this week, and I'd like to try to push out 2.6 a1 (which we're already running a little behind on). -Brian Hi all - I never heard anything back from this. Are we still on for tomorrow? Hmm, too much rush here, sorry, I won't make it. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] problems with accented characters - need advice
Florent Guillaume [EMAIL PROTECTED] wrote: Toby Dickenson [EMAIL PROTECTED] wrote: On Tuesday 18 Jun 2002 8:44 pm, Dieter Maurer wrote: The reason why it is still there is that a change should work for all languages and not only western ones. This poses the question how the byte string representing the id your should be URL quoted. There is an RFC, I forget which one, which specifies utf8. I'm not sure about that, last time I digged I found that it was explicitely said in the RFCs that no encoding was specified and that it was up to the application to decide what to use. To be precise: RFC 2068 (HTTP 1.1) says: For definitive information on URL syntax and semantics, see RFC 1738 [4] and RFC 1808 [11]. The BNF above includes national characters not allowed in valid URLs as specified by RFC 1738, since HTTP servers are not restricted in the set of unreserved characters allowed to represent the rel_path part of addresses, and HTTP proxies may receive requests for URIs not defined by RFC 1738. RFC 1808 (URL) doesn't talk about charset or bytes. RFC 2396 (URI, updates RFC 1808 RFC 1738) says, and I'll quote extensively. Note the last two paragraphs. 2.1 URI and non-ASCII characters The relationship between URI and characters has been a source of confusion for characters that are not part of US-ASCII. To describe the relationship, it is useful to distinguish between a character (as a distinguishable semantic entity) and an octet (an 8-bit byte). There are two mappings, one from URI characters to octets, and a second from octets to original characters: URI character sequence-octet sequence-original character sequence A URI is represented as a sequence of characters, not as a sequence of octets. That is because URI might be transported by means that are not through a computer network, e.g., printed on paper, read over the radio, etc. A URI scheme may define a mapping from URI characters to octets; whether this is done depends on the scheme. Commonly, within a delimited component of a URI, a sequence of characters may be used to represent a sequence of octets. For example, the character a represents the octet 97 (decimal), while the character sequence %, 0, a represents the octet 10 (decimal). There is a second translation for some resources: the sequence of octets defined by a component of the URI is subsequently used to represent a sequence of characters. A 'charset' defines this mapping. There are many charsets in use in Internet protocols. For example, UTF-8 [UTF-8] defines a mapping from sequences of octets to sequences of characters in the repertoire of ISO 10646. In the simplest case, the original character sequence contains only characters that are defined in US-ASCII, and the two levels of mapping are simple and easily invertible: each 'original character' is represented as the octet for the US-ASCII code for it, which is, in turn, represented as either the US-ASCII character, or else the % escape sequence for that octet. For original character sequences that contain non-ASCII characters, however, the situation is more difficult. Internet protocols that transmit octet sequences intended to represent character sequences are expected to provide some way of identifying the charset used, if there might be more than one [RFC2277]. However, there is currently no provision within the generic URI syntax to accomplish this identification. An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used. It is expected that a systematic treatment of character encoding within URI will be developed as a future modification of this specification. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Temp Folders and Transient Object Containers
Under the category of feigning smartness by blindly copying what I see, In a subfolder of the Zope root, I set up a browser_id_manager, a session_data_manager, a temp folder (cleverly named 'temp_folder'), and put a Transient Object Container inside that temp folder, named 'tix_sessions'. Of course, when I restarted Zope, the 'tix_sessions' object itself was gone. So, why is the default Transient Object Container put in a Temporary Folder? If I want to use an application specific one that doesn't get lost on restart, is it OK to put it into a normal persistent folder? -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] let's just get rid of it (was: Last-modified andbobobase_modification_time)
Leonardo Rochael Almeida writes: IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time. Most Zope objects do not send Last-Modified headers, unless you use an HTTP cache manager. File objects (and derived objects) do but there it is justified. However, Zope seems to send a bogus ETag header. The HTTP spec says that the ETag must uniquely identify the current incarnation of the entity. Especially, the ETag should change, when the entity is modified. But Zope sends empty ETag headers, allowing HTTP compatible caches to cache the pages. This seems to be a bug with the consequence of unanticipated caching problems. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] let's just get rid of it (was: Last-modified andbobobase_modification_time)
The sending of an empty ETag header is a workaround to get Zope working with M$ Office through Webdav. But this header should be only be send on the WebDAV port. Andreas --On Thursday, June 20, 2002 21:16 +0200 Dieter Maurer [EMAIL PROTECTED] wrote: Leonardo Rochael Almeida writes: IMHO, Last-modified does not make sense for dynamically calculated pages, as most zope pages are. We should just not provide this header, or provide with the value of the current time. Most Zope objects do not send Last-Modified headers, unless you use an HTTP cache manager. File objects (and derived objects) do but there it is justified. However, Zope seems to send a bogus ETag header. The HTTP spec says that the ETag must uniquely identify the current incarnation of the entity. Especially, the ETag should change, when the entity is modified. But Zope sends empty ETag headers, allowing HTTP compatible caches to cache the pages. This seems to be a bug with the consequence of unanticipated caching problems. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) - -Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - -Life is too short to (re)write parsers - - ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Temp Folders and Transient Object Containers
So, why is the default Transient Object Container put in a Temporary Folder? If I want to use an application specific one that doesn't get lost on restart, is it OK to put it into a normal persistent folder? Yup. The TOC is put into the temp folder mostly because: 1) Sessions are write-intensive and cause bloat on undoing storages like FileStorage. 2) Sessions are write-intensive and cause conflicts when accessed via a normal ZODB connection. The temp folder is mounted into a database which has a special low conflict connection type that ignores read conflict errors. You will get more conflicts and more bloat if you put a TOC into a normal persistent folder (esp. one backed by FileStorage), but it will work. That said, there are a few bugs in the 2.5 transience implementation that I'm working on as we speak that might be more egregious if you have a truly persistent TOC, so pls. keep an eye towards 2.6 (or CVS ;-) in the next few weeks. You will notice the bugs in the form of phantom key errors (not unlike the old Catalog bugs ;-) - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Temp Folders and Transient Object Containers
On 6/20/02 4:01 PM, Chris McDonough [EMAIL PROTECTED] wrote: So, why is the default Transient Object Container put in a Temporary Folder? If I want to use an application specific one that doesn't get lost on restart, is it OK to put it into a normal persistent folder? Yup. The TOC is put into the temp folder mostly because: 1) Sessions are write-intensive and cause bloat on undoing storages like FileStorage. 2) Sessions are write-intensive and cause conflicts when accessed via a normal ZODB connection. The temp folder is mounted into a database which has a special low conflict connection type that ignores read conflict errors. You will get more conflicts and more bloat if you put a TOC into a normal persistent folder (esp. one backed by FileStorage), but it will work. That said, there are a few bugs in the 2.5 transience implementation that I'm working on as we speak that might be more egregious if you have a truly persistent TOC, so pls. keep an eye towards 2.6 (or CVS ;-) in the next few weeks. You will notice the bugs in the form of phantom key errors (not unlike the old Catalog bugs ;-) Oh yes. Those were fun days! So, I want to have different TOC's, preferably in non persistent folders (the site I'm working on could be quite high traffic at times). A big problem is - if one is in a temporary folder, it will disappear if Zope ever restarts. So, at present, it looks like you can only have one reliable non-persistent TOC per Zope instance, since that one's always initialized during the time Zope is checking its root for required objects (Zope 2.5.1 lib/python/OFS/Applicatoin.py (revision 1.179.4.1), starting at line 277). This could be a rather crappy situation for Zope instances hosting multiple applications with different Session requirements. Fortunately for the project I'm on, I think it will have a dedicated Zope instance. No one's working on a Kinda Sorta Temporary Folder are they? ;) Or, as Jim might put it Temporary, except for when I don't want it to be. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Temp Folders and Transient Object Containers
I would probably work around this by creating a Product that gets a hold of the app object in its __init__ and creates all the necessary stuff. Actually, it would be kinda nice if instead of creating only the session_data object in the temp_folder initialization code we imported some (replaceable) arbitrary .zexp file that contained whatever you wanted. You could hack something up like this I'm sure. Oh yes. Those were fun days! So, I want to have different TOC's, preferably in non persistent folders (the site I'm working on could be quite high traffic at times). A big problem is - if one is in a temporary folder, it will disappear if Zope ever restarts. So, at present, it looks like you can only have one reliable non-persistent TOC per Zope instance, since that one's always initialized during the time Zope is checking its root for required objects (Zope 2.5.1 lib/python/OFS/Applicatoin.py (revision 1.179.4.1), starting at line 277). This could be a rather crappy situation for Zope instances hosting multiple applications with different Session requirements. Fortunately for the project I'm on, I think it will have a dedicated Zope instance. No one's working on a Kinda Sorta Temporary Folder are they? ;) Or, as Jim might put it Temporary, except for when I don't want it to be. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Last-modified and bobobase_modification_time
Ah, well, that is not quite true. Zope (And apache, IIS, and others) may do the right thing and set or not set the headers, but IE at least definately DOES NOT do the correct thing when it comes to caching on the client (Even with caching disabled it still caches when it feels like it). Until clients improve, caching is just bad IMHO. Adrian... -- Adrian Hungate EMail: [EMAIL PROTECTED] Web: http://www.haqa.co.uk - Original Message - From: Wei He [EMAIL PROTECTED] To: Toby Dickenson [EMAIL PROTECTED] Cc: Dieter Maurer [EMAIL PROTECTED]; R. David Murray [EMAIL PROTECTED]; Chris Withers [EMAIL PROTECTED]; Casey Duncan [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 20, 2002 2:45 PM Subject: Re: [Zope-dev] Last-modified and bobobase_modification_time On Thu, 20 Jun 2002, Toby Dickenson wrote: In either case, Zope's current implementation needs to be changed. Because it will give the client a false impression that a page has not changed but actually it did. What part of Zope gets this wrong? I just realized that the Last-Modified header in a GET request is NOT sent for a dynamic page. I was always asuming that it is the same as the HEAD request of the same URL. So at least the user can get correct information cause the client cache function will not work. Whether a cache server can handle this situation or whether RFC allows doing this (haven't read yet) is not a big problem. Sorry to everyone. And thank all of you. Wei He ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
