...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :( For a couple of things that were ready to go and fairly non controversial (like Toby's unicode work), I put on the BDFL hat and said "merge it!". But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them. I'll volunteer to convert the current proposed feature list into a draft "plan", where the conversion boils down to adding some columns to the table: Proposal - name and link to the proposal Resources - who is working on it Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week in June. I'll fill in what I know has been committed to, people can update this (or let me know and I'll do it), and anything that doesn't get a 'Y' in a reasonably short time will be put in the cooler. Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next order of business. Getting to closure on those either via the list, IRC, or whatever is the main block on the critical path. Status - Complete or incomplete I've taken a first stab at this. I've set the "committed" to 'Y' for those things that I know I've gotten commitments for. For those set to 'N', please let me know if you can commit to the date (or change it yourself in the wiki). The updated plan is at: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures Once we get the commitments up to date, we can start wrangling with the vetting... Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
At 13:47 09-04-2002 -0400, Brian Lloyd wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them.
Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week
Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next
Hi: Both me and Myroslav Opyr <myroslav@zope.net.ua> are quite commited to do the proposed "Object Links/References". Although from the emails we exchanged with you, I would've guessed that it was one of the "controversial enough" to be a Vetted item :-) Anyways I'm commited to do it. I do agree with your argument about link semantics but, at least for me, a link/reference is a link, and the semantics are perfectly defined i.e its not a RedirectObject. As in Unix, a hard link has different semantics from a soft link. I'm thinking of the "hard link" semantics. C U! -- Mario Valente
Both me and Myroslav Opyr <myroslav@zope.net.ua> are quite commited to do the proposed "Object Links/References". Although from the emails we exchanged with you, I would've guessed that it was one of the "controversial enough" to be a Vetted item :-)
Anyways I'm commited to do it. I do agree with your argument about link semantics but, at least for me, a link/reference is a link, and the semantics are perfectly defined i.e its not a RedirectObject.
As in Unix, a hard link has different semantics from a soft link. I'm thinking of the "hard link" semantics.
I guess that what I was getting at is that the semantics for this need to be spelled out in detail so that we can make sure that they make sense before something like this goes in. Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :) We need to spell out the exact semantics (*especially* wrt security, but also in terms of its effect on ZODB identity semantics, effects on undo, etc.) Security in particular is very concerned with *containment* path (rather than just acquisition path) in order to prevent "stealing" access through acquisition wrappers. Having objects with more than one "place" may introduce much the same problem, so we'll need to write up in detail the effects on the security machinery or its application to domain objects (or if the security machinery does not need to change, we need to spell out why). Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
Both me and Myroslav Opyr <myroslav@zope.net.ua> are quite commited to do the proposed "Object Links/References". Although from the emails we exchanged with you, I would've guessed that it was one of the "controversial enough" to be a Vetted item :-)
Anyways I'm commited to do it. I do agree with your argument about link semantics but, at least for me, a link/reference is a link, and the semantics are perfectly defined i.e its not a RedirectObject.
As in Unix, a hard link has different semantics from a soft link. I'm thinking of the "hard link" semantics.
I guess that what I was getting at is that the semantics for this need to be spelled out in detail so that we can make sure that they make sense before something like this goes in.
Ok. Let's find out what we have and what we want. First of all we have strict hierarchy in ZODB where each object appears only once in the tree. Thus to access to an object it is only one way from root down to an object through containers. All security in Zope is based on that pattern. I am omitting Acquisition machinery to simplify (and I do not see it clearly in the context here). The idea is to allow user to specify several points of presence (pop) for an object. Does this break security? Probably yes, but in what case? If an object from higly secure envionment appeared somewhere in Anonymous zone, what then? Yes, Anonymous is able to alter object. But there was reason for that! Is Anonymous able to get out of the shared object to secure environment? No in no simple way. Sure if an object was DTML and Anonymous placed trojan horse in the script and someone from secure environment executed the code then we run in a problem. But we can warn user! And we have a lot of "Restricted..." techniques, maybe one can be applied here?
Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :) We need to spell out the exact semantics (*especially* wrt security, but also in terms of its effect on ZODB identity semantics, effects on undo, etc.)
Ok. I am not too well in English but I'll try to do my best. If it is not hard for you give several words of explanation of "ZODB identity semantics" and "effects on undo", not everything is clear for me.
Security in particular is very concerned with *containment* path (rather than just acquisition path) in order to prevent "stealing" access through acquisition wrappers. Having objects with more than one "place" may introduce much the same problem, so we'll need to write up in detail the effects on the security machinery or its application to domain objects (or if the security machinery does not need to change, we need to spell out why).
Why we are not willing to allow such scenario? AFAIK there was and are a lot of concernes refarding soft- and hardlinks in /tmp folder, with sticky bit, etc... But they are usually solved with different means. Yes, Zope and ZODB is much more complex. But why we have to limit ourselves because something is difficult. Why not mark the feature as experimental (red button, a lot of warnings, for instance) and make it available to SuperManager only ;) I'd be glad to get feedback, thanks, Myroslav -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578
The idea is to allow user to specify several points of presence (pop) for an object. Does this break security? Probably yes, but in what case? If an object from higly secure envionment appeared somewhere in Anonymous zone, what then? Yes, Anonymous is able to alter object. But there was reason for that!
Maybe - but maybe you just made the link without realizing the effect on security. That is one of the biggest conceptual problems here. Security behavior has to be as simple and understandable as possible for it to be useful. If people don't feel like they understand it, they will always have a nagging fear that they are vulnerable - and they will probably be right. One could argue that we are already pushing the boundaries with the current security implementation, which is why the bar is so high for adding things to the core that potentially make things more complex yet.
Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :) We need to spell out the exact semantics (*especially* wrt security, but also in terms of its effect on ZODB identity semantics, effects on undo, etc.)
Ok. I am not too well in English but I'll try to do my best. If it is not hard for you give several words of explanation of "ZODB identity semantics" and "effects on undo", not everything is clear for me.
Undo uses the "place" of an object as part of the criteria for deciding whether you can undo changes to it. If the meaning of "place" changes, undo behavior is likely to change. To use your earlier example, now Anonymous users might be able to undo changes made by a manager (in a different "place" on the "same" object). Is this acceptable? I don't know, but before we think about allowing changes like this into the core, the differences in behavior need to be spelled out in detail with specific examples. Likewise with ZODB. What effects would links have on cache behavior (which are based on persistent identity)? On packing behavior?
Why we are not willing to allow such scenario? AFAIK there was and are a lot of concernes refarding soft- and hardlinks in /tmp folder, with sticky bit, etc... But they are usually solved with different means. Yes, Zope and ZODB is much more complex. But why we have to limit ourselves because something is difficult.
I'm not trying to say that we shouldn't do something because it is difficult - just that in order to make changes like this we need to elaborate and understand all of the details and have a workable answer for all of the problems.
Why not mark the feature as experimental (red button, a lot of warnings, for instance) and make it available to SuperManager only ;)
Because that's the textbook case for making it a Product :) We shouldn't be putting things in the core that come with flashing red warnings and can only be used by superusers. What is wrong with leaving this as an add-on product? Why does it _need_ to be a part of the core at all? Useful products are useful, whether or not they "come with Zope", and there are plenty of very useful products that don't come built in. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
At 10:06 10-04-2002 -0400, Brian Lloyd wrote:
What is wrong with leaving this as an add-on product? Why does it _need_ to be a part of the core at all? Useful products are useful, whether or not they "come with Zope", and there are plenty of very useful products that don't come built in.
I totally agree. Thats what I previously thought was the case: that your earlier comments were very much towards the "links" stuff being "Vetted" and that it should be released as a patch/product. C U! -- MV
On Wed, 10 Apr 2002 01:30:56 +0300, Myroslav Opyr <myroslav@zope.net.ua> wrote:
Is Anonymous able to get out of the shared object to secure environment?
User X is designated as a manager of folder /Xfolder. In todays Zope /Xfolder is a secure environment.... He has no authority over objects outside that folder, thanks to aq_inContextOf Can he create links to objects outside that folder? Links would be pretty useless if not. A common use case would be to create a link /XFolder/banner.gif to /stock_images/banners/mono.gif (for example). However if that is allowed, he now has management rights over that image object. I dont see how 'hard links' can possibly avoid this problem. Toby Dickenson tdickenson@geminidataloggers.com
At 15:12 10-04-2002 +0100, Toby Dickenson wrote:
User X is designated as a manager of folder /Xfolder. In todays Zope /Xfolder is a secure environment.... He has no authority over objects outside that folder, thanks to aq_inContextOf
Can he create links to objects outside that folder?
No, he cant. To create a link (my hack...) you first need to obtain the object reference (moniker) with a Copy operation so that you can then do a "Paste Ref." operation.
Links would be pretty useless if not.
No they wouldnt.
A common use case would be to create a link /XFolder/banner.gif to /stock_images/banners/mono.gif (for example).
However if that is allowed, he now has management rights over that image object.
I dont see how 'hard links' can possibly avoid this problem.
Right. But they would be useful to put an image in /Xfolder/images/ and then be able to paste links to it into /Xfolder/layout1/ and /Xfolder/layout2/ and /Xfolder/Development without the need to create multiples instances of the same image or without coding multiple requests for that object. C U! -- MV
At 01:30 10-04-2002 +0300, Myroslav Opyr wrote:
Ok. Let's find out what we have and what we want. First of all we have strict hierarchy in ZODB where each object appears only once in the tree. Thus to access to an object it is only one way from root down to an object through containers.
The idea is to allow user to specify several points of presence (pop) for an object.
Precisely. My first hack solves this and I've been using it OK in production sites. But I didnt like the fact that an object "point of presence" in the Zope tree was identical in every instance. That leads to confusion. My second hack creates a ProxyObject class thus allowing for a different metatype and a different icon. This reduces confusion. And you can also provide a management tab with links to the "original" object "point of presence". I tried using Python 2.1 Proxy classes but Acquisition wasnt "proxiable"... C U! -- MV
At 14:38 09-04-2002 -0400, Brian Lloyd wrote:
As in Unix, a hard link has different semantics from a soft link. I'm thinking of the "hard link" semantics.
Comparing it to Unix hard links is fine, but Unix doesn't use Acquisition to handle security, so the comparison is not apples-to-apples :)
No its not, agreed. But actually, when you create a hard link to an executable file and from within that executable request the path, you'll get different paths. Crappy way of doing security, but there's lots of people doing it :-) I guess you could call that acquisition :-)
Security in particular is very concerned with *containment* path (rather than just acquisition path) in order to prevent "stealing" access through acquisition wrappers. Having objects with more than one "place" may introduce much the same problem, so we'll need to write up in detail the effects on the security machinery or its application to domain objects (or if the security machinery does not need to change, we need to spell out why).
I wouldnt mind doing this, but I think its out of my league.... C U! -- MV
On Tue, 2002-04-09 at 13:47, Brian Lloyd wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
For a couple of things that were ready to go and fairly non controversial (like Toby's unicode work), I put on the BDFL hat and said "merge it!".
But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them.
I'll volunteer to convert the current proposed feature list into a draft "plan", where the conversion boils down to adding some columns to the table:
Proposal - name and link to the proposal
Resources - who is working on it
Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week in June. I'll fill in what I know has been committed to, people can update this (or let me know and I'll do it), and anything that doesn't get a 'Y' in a reasonably short time will be put in the cooler.
Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next order of business. Getting to closure on those either via the list, IRC, or whatever is the main block on the critical path.
Status - Complete or incomplete
I've taken a first stab at this. I've set the "committed" to 'Y' for those things that I know I've gotten commitments for. For those set to 'N', please let me know if you can commit to the date (or change it yourself in the wiki).
The updated plan is at:
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
Once we get the commitments up to date, we can start wrangling with the vetting...
ICP support is already checked in; may need to be documented. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Support for X-HTTPD-FORWARDED-FOR Code for this is pretty simple: modify 2 files, ZServer/medusa/http_server.py and lib/python/AccessControl/User.py 1. To put the proxy-passed ip address in the zserver log, Around line 269 in ZServer/medusa/http_server.py, add a method http_request::client_ip def client_ip(self): proxy_client = self.get_header('x-forwarded-for') if proxy_client: return proxy_client else: return self.channel.addr[0] Then around line 294, change the statement that does logging to use the method. self.channel.server.logger.log ( self.client_ip(), ' - %s [%s] "%s" %d %d "%s" "%s"\n' % ( name, ... 2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do, In lib/python/AccessControl/User.py, around line 1116, change if request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] to if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR'] I do not believe this does anything to authentication that is not possible now regarding spoofed ip addresses, so probably not a major security headache. Major possible problem I can think of: I do not use ZEO, and have no idea what these changes might do there. I do not have check-in privileges, and probably should not until I get a better clue of how cvs works :). Anyway, here is the code FWIW. Apologies that it is not a patch per se. Now looking for a more clueful sponsor to take it from here to check-in (after vetting?) -- Jim Washington Brian Lloyd wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
For a couple of things that were ready to go and fairly non controversial (like Toby's unicode work), I put on the BDFL hat and said "merge it!".
But there are still a lot of things on the proposed features that are undone, and some that are controversial enough that we need to get to closure on them.
I'll volunteer to convert the current proposed feature list into a draft "plan", where the conversion boils down to adding some columns to the table:
Proposal - name and link to the proposal
Resources - who is working on it
Committed - Y/N whether the volunteers have committed to have the implementation and docs done by the first week in June. I'll fill in what I know has been committed to, people can update this (or let me know and I'll do it), and anything that doesn't get a 'Y' in a reasonably short time will be put in the cooler.
Vetted - Y / N whether the community and / or the relevant BDFLs have come to some agreement on whether it *should* be done. The list of items without a 'Y' will be our next order of business. Getting to closure on those either via the list, IRC, or whatever is the main block on the critical path.
Status - Complete or incomplete
I've taken a first stab at this. I've set the "committed" to 'Y' for those things that I know I've gotten commitments for. For those set to 'N', please let me know if you can commit to the date (or change it yourself in the wiki).
The updated plan is at:
http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures
Once we get the commitments up to date, we can start wrangling with the vetting...
Jim Washington wrote:
2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do,
In lib/python/AccessControl/User.py, around line 1116, change
if request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
to
if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
I do not believe this does anything to authentication that is not possible now regarding spoofed ip addresses, so probably not a major security headache.
Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play. It's just adding a custom header to the request. I also doubt that every reverse proxy overwrites this header, so zservers behind a proxy might also be hit. TCP spoofing OTOH is far more complicated, if (does it?) zope turns off the source routing option when replying, if present. IMO something like cracking a router or predicting sequence numbers is another level from adding a custom http-header. cheers, oliver
On Wed, Apr 10, 2002 at 06:59:38PM +0200, Oliver Bleutgen wrote:
Jim Washington wrote:
2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do,
In lib/python/AccessControl/User.py, around line 1116, change
if request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
to
if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
I do not believe this does anything to authentication that is not possible now regarding spoofed ip addresses, so probably not a major security headache.
Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play. It's just adding a custom header to the request. I also doubt that every reverse proxy overwrites this header, so zservers behind a proxy might also be hit.
Note: this is using another web server to front for zope. It turns out to be fairly safe -- I have used a variant for quite a while and did quite a bit of testing. For short hand, I am going to call the other web server apache. Apache presumably uses something like getpeername to fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR. If the remote user attempts to spoof it (by using hidden variables, or other HTTP based techniques), the Zope server interprets this is a list, rather than the expected string. This is easy to detect, and in fact, if you fail to handle it, you will probably simply error out. If the attacker is using TCP spoofing, there is really not much you can do at an application level. On the other hand, I am now conviced that this is not an intelligent thing to do, not even for presentation. You already have Apache in front, so why not use rewriting rules to make the URL distinguishable. In this way, you can use one of the BASE or URL variables to determine how the person got in. This gives you pretty much the same level of control (especially if you are worried only about internal/external) as using IP addresses, without modifying either Zope or Apache. Jim Penny
TCP spoofing OTOH is far more complicated, if (does it?) zope turns off the source routing option when replying, if present. IMO something like cracking a router or predicting sequence numbers is another level from adding a custom http-header.
cheers, oliver
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play. It's just adding a custom header to the request. I also doubt that every reverse proxy overwrites this header, so zservers behind a proxy might also be hit.
Note: this is using another web server to front for zope. It turns out to be fairly safe -- I have used a variant for quite a while and did quite a bit of testing. For short hand, I am going to call the other web server apache. Apache presumably uses something like getpeername to fill in its idea of HTTP_X_FORWARDED_FOR or REMOTE_ADDR. If the remote user attempts to spoof it (by using hidden variables, or other HTTP based techniques), the Zope server interprets this is a list, rather than the expected string. This is easy to detect, and in fact, if you fail to handle it, you will probably simply error out.
If the attacker is using TCP spoofing, there is really not much you can do at an application level.
On the other hand, I am now conviced that this is not an intelligent thing to do, not even for presentation. You already have Apache in front, so why not use rewriting rules to make the URL distinguishable. In this way, you can use one of the BASE or URL variables to determine how the person got in. This gives you pretty much the same level of control (especially if you are worried only about internal/external) as using IP addresses, without modifying either Zope or Apache.
Jim, Oliver Thanks. I'm glad we have smart and knowledgeable people available to discuss these kinds of things. My hope was that I could restrict my Manager account to a short list of machines, even through a squid or apache proxy. Essentially add a third thing to have besides username and password. Which I still think is better than just username and password, since Zope sees only *one* ip address coming from squid in the current situation. I'll have to do some more thinking... Regards, -- Jim Washington
On Wed, 10 Apr 2002 12:16:35 -0400, Jim Washington <jwashin@vt.edu> wrote:
2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do,
to
if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
There are lots of things that use REMOTE_ADDR, and I guess they should *all* use the proxy supplied address rather than the address of the proxy. It makes sense to me that we should *replace* REMOTE_ADDR with HTTP_X_FORWARDED_FOR at the earliest opportunity. (and create a X_FORWARDED_BY) Have you considered this approach? On Wed, 10 Apr 2002 18:59:38 +0200, Oliver Bleutgen <myzope@gmx.net> wrote:
Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play.
Thats correct for a naked ZServer, or if behind a proxy which does not sanitize the X-FORWARDED-FOR header. However it is safe if the request comes from the right kind of proxy. I think we need a new command line option to specify a list of IP addresses which are trusted to run 'the right kind of proxy'. Zope should only trust the X-FORWARDED-FOR header if the remote address is one of its trusted proxies. Pseudocode for handling this would be: if request['REMOTE_ADDR'] in our_trusted_front_end_proxies: request['HTTP_X_FORWARDED_BY'] = request['REMOTE_ADDR'] request['REMOTE_ADDR'] = request['HTTP_X_FORWARDED_FOR'] Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
On Wed, 10 Apr 2002 12:16:35 -0400, Jim Washington <jwashin@vt.edu> wrote:
2. If we want to get fancy about allowing authentication using that ip address like naked ZServers can do,
to
if request.has_key('HTTP_X_FORWARDED_FOR'): addr=request['HTTP_X_FORWARDED_FOR'] elif request.has_key('REMOTE_ADDR'): addr=request['REMOTE_ADDR']
There are lots of things that use REMOTE_ADDR, and I guess they should *all* use the proxy supplied address rather than the address of the proxy. It makes sense to me that we should *replace* REMOTE_ADDR with HTTP_X_FORWARDED_FOR at the earliest opportunity. (and create a X_FORWARDED_BY)
Have you considered this approach?
Not yet, but I like the idea... As with Oliver's reply, this I think would need some research. I will be refining what I mean by "support" in the subject line shortly.
On Wed, 10 Apr 2002 18:59:38 +0200, Oliver Bleutgen <myzope@gmx.net> wrote:
Correct me if I'm wrong, but this IMO makes spoofing against a naked ZServer a childs play.
Thats correct for a naked ZServer, or if behind a proxy which does not sanitize the X-FORWARDED-FOR header. However it is safe if the request comes from the right kind of proxy.
I think we need a new command line option to specify a list of IP addresses which are trusted to run 'the right kind of proxy'. Zope should only trust the X-FORWARDED-FOR header if the remote address is one of its trusted proxies.
Pseudocode for handling this would be:
if request['REMOTE_ADDR'] in our_trusted_front_end_proxies: request['HTTP_X_FORWARDED_BY'] = request['REMOTE_ADDR'] request['REMOTE_ADDR'] = request['HTTP_X_FORWARDED_FOR']
Excellent! Except for command-line bloat. With Matt Behrens's config proposal (http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration), this nevertheless could be workable. Things are looking up. Maybe. Ummmm..., more research... -- Jim Washington
On Tue, Apr 09, 2002 at 01:47:49PM -0400, Brian Lloyd wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6 How about 'vetted' - It's set to N, when will I know if I should start coding? Cheers Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/ Consultancy Email: ivo@amaze.nl -=-
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6
How about 'vetted' - It's set to N, when will I know if I should start coding?
Ivo - I don't have a problem with the spelling of this. I _do_ have a problem with the fact that it (your existing release) actually stores the variable in REQUEST. If it were to store them somewhere more appropriate in the DTML namespace stack, I'd be happy to OK it. We'd also need someone to commit to providing the extra docs for the help system and the dtml reference section of the online Zope book. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Tuesday 16 April 2002 03:44 pm, Brian Lloyd wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
By the way, Brian, if I can with the remaining amount of time left, I'll do the work I volunteered to do. However, perhaps I speak for others in that I look to you and ZC for leadership as to *whether* I should do the work. I simply don't know how to vet the list, and I feel like you guys are the leaders. I offered to help, and I meant it, but I feel you guys are the leaders for this, particularly for a release, for what seems to be obvious reasons. So, at least to go back to basics and give you a practical answer to your question of ancient history, I have no idea how to vet the list. If it is vetted and I am called on to do some work, then I'm happy to do it if my schedule still permits it by the time the decision is made. This seems like another community initiative that fizzled: at least in my part that is so because I felt you guys should lead this, but I never got around to telling you so. So, sorry. :-( But better late than never, perhaps. Maybe other folks disagree. Thanks. Gary
By the way, Brian, if I can with the remaining amount of time left, I'll do the work I volunteered to do. However, perhaps I speak for others in that I look to you and ZC for leadership as to *whether* I should do the work. I simply don't know how to vet the list, and I feel like you guys are the leaders.
I offered to help, and I meant it, but I feel you guys are the leaders for this, particularly for a release, for what seems to be obvious reasons.
Ok :) As far as "vetting" virtual host folder, my concerns boil down to: a. dependency / requirement for ordered folder b. having yet another virtual host thing in the core will confuse people I suppose that (a) can be gotten around by embedding the required functionality (or adding ordering to folders by default). Easy enough. The "hard part" on this proposal is deciding whether having another virtual host solution in the core (rather than as an add-on) is worth the impact on user experience. We've already learned the hard way that the existing SiteRoots and VirtualHostMonsters etc. confuse people. This is partly due to under-documentation, but it is also partly because of the "here, we'll give you several ways to do it!" approach. We've taken our share of beatings over the current situation, so I'm reticent about adding another way unless there is a very strong reason for it be a part of the core rather than remain an add-on component. (Maybe that's because I seem to catch a fair amount of the beatings, when they come :) If there are strong reasons for it to be in the core, then I suspect it would need to be sufficient to be the "official" VH solution and we'd want to deprecate the existing things. That means that it will need to be well documented, and we'll need to produce the needed deprecation docs, transition guides, etc. My other concern is maintenance. Adding big new parts like this to the core requires an ongoing commitment, and ZC is spread way too thin already. The upshot here is that there will be some natural resistance to putting significant additions into the core without someone stepping up to maintain it on an ongoing basis. If you are willing to do that, then I'm not so concerned about that point. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
From: "Brian Lloyd" <brian@zope.com>
a. dependency / requirement for ordered folder
I agree. But ordering is the simple part of this, and could be done without orderedfolder. Does VHF use something else of orderedfolder? I think that has been asked before, but I don't remember the answer.
We've already learned the hard way that the existing SiteRoots and VirtualHostMonsters etc. confuse people. This is partly due to under-documentation, but it is also partly because of the "here, we'll give you several ways to do it!" approach.
Yup. Therefore I think that the host monster shouldn't be included. VHF should supercede it. There is an alternative, and that is to clean up the enhanced enhanced virtual host monster we at Torped have done. It's based on sfm@imemes enhanced VHM and just like VHF is makes it possible to have standalone virtual hosting without strange apache magic. We added an API to translate virtual to physical paths and back. I don't like that as much, though. If backwards compatibility is desired, add warning messages for usage and remove the VHM from the add box, but continue to include it in the code. :-)
On Wednesday 17 April 2002 11:52 am, Lennart Regebro wrote:
From: "Brian Lloyd" <brian@zope.com>
a. dependency / requirement for ordered folder
I agree. But ordering is the simple part of this, and could be done without orderedfolder. Does VHF use something else of orderedfolder? I think that has been asked before, but I don't remember the answer.
It can take advantage of the OrderedFolder metatype limitations (since ZClasses seem to mess up the code-based limits, at least in my zopes) but it doesn't have to. I had a built-in OrderedFolder-alike that I used for my initial releases; it would feel like a bit of a step back to return to that but I suppose I could if folks desired.
We've already learned the hard way that the existing SiteRoots and VirtualHostMonsters etc. confuse people. This is partly due to under-documentation, but it is also partly because of the "here, we'll give you several ways to do it!" approach.
Yup. Therefore I think that the host monster shouldn't be included. VHF should supercede it.
If there is enough interest in doing this that I don't have to feel like a "lone maintainer" (i.e., other folks would be willing to step up to bat for it when I can't) then I'd be more willing.
There is an alternative, and that is to clean up the enhanced enhanced virtual host monster we at Torped have done. It's based on sfm@imemes enhanced VHM and just like VHF is makes it possible to have standalone virtual hosting without strange apache magic. We added an API to translate virtual to physical paths and back.
That would be fine too. :-) Gary
Lennart Regebro wrote:
Yup. Therefore I think that the host monster shouldn't be included. VHF should supercede it.
If backwards compatibility is desired, add warning messages for usage and remove the VHM from the add box, but continue to include it in the code. :-)
Just as a passing comment from an extensive user of the normal virtual host monster: What you're suggesting sux badly, please leave it as it is! cheers, Chris
Lennart Regebro wrote:
There is an alternative, and that is to clean up the enhanced enhanced virtual host monster we at Torped have done. It's based on sfm@imemes enhanced VHM and just like VHF is makes it possible to have standalone virtual hosting without strange apache magic. We added an API to translate virtual to physical paths and back.
Just so you know, a limited version of the imeme enhancements is in the Zope 2.5 VHM, and there is a standard REQUEST API consisting of physicalPathToVirtualPath, physicalPathToURL, and physicalPathFromURL. Cheers, Evan @ 4-am
On Wednesday 17 April 2002 11:48 am, Brian Lloyd wrote:
Ok :) As far as "vetting" virtual host folder, my concerns boil down to:
a. dependency / requirement for ordered folder
b. having yet another virtual host thing in the core will confuse people
...
Hey Brian. Thanks for your response. All points understood and appreciated. And I guess, then, that I'll choose not to make that commitment, since I'm looking forward to Zope3 these days anyway. If folks still want OrderedFolder (or, at least ordering capability) in the core I'm still willing to help with that. Thanks again. Gary
On 4/17/02 9:56 AM, "Gary Poster" <garyposter@earthlink.net> wrote:
On Wednesday 17 April 2002 11:48 am, Brian Lloyd wrote:
Ok :) As far as "vetting" virtual host folder, my concerns boil down to:
a. dependency / requirement for ordered folder
b. having yet another virtual host thing in the core will confuse people
...
Hey Brian. Thanks for your response.
All points understood and appreciated.
And I guess, then, that I'll choose not to make that commitment, since I'm looking forward to Zope3 these days anyway.
If folks still want OrderedFolder (or, at least ordering capability) in the core I'm still willing to help with that.
I'm a little surprised this hasn't come up for inclusion earlier. When showing a site to some top-management folk in a previous life, the question that came up most often was "can we organize those links on the side so that blablabla is first?". One person would ask it, I'd respond with the "hmmm, not easily - at least, not in time for our deployment date". Then the next person would come in late to the meeting, ask the same question, we'd laugh and tell them the scenario - "to make admin easy, it's just listing the documents in that folder that are public, using the API's already available!". They'd go OK. The tour continued. Another straggler comes in, the loop repeated itself... :). For "add-to-the-core" functionality, I'll vote +0.5. I wouldn't mind seeing it in the core, but I also like the idea someone mentioned of a sort of "expansion pack" of other good products that was well maintained alongside each core release. -- Jeffrey P Shell www.cuemedia.com
On Wed, 17 Apr 2002 17:54:12 -0600, Jeffrey P Shell <jeffrey@cuemedia.com> wrote:
On 4/17/02 9:56 AM, "Gary Poster" <garyposter@earthlink.net> wrote:
If folks still want OrderedFolder (or, at least ordering capability) in the core I'm still willing to help with that.
For "add-to-the-core" functionality, I'll vote +0.5. I wouldn't mind seeing it in the core, but I also like the idea someone mentioned of a sort of "expansion pack" of other good products that was well maintained alongside each core release.
I agree with both of these two points that Jeffrey made. It is a sore omission from the core, but I cant see any place to hook the user interface that doesnt amount to "bloat" for many folders that dont need. Does it make sense to include an ObjectManager.manage_reorderItems method in the core, but leave the user interface to expansion pack products ? Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
I agree with both of these two points that Jeffrey made. It is a sore omission from the core, but I cant see any place to hook the user interface that doesnt amount to "bloat" for many folders that dont need.
Does it make sense to include an ObjectManager.manage_reorderItems method in the core, but leave the user interface to expansion pack products ?
I think the UI for reordering should be switchable, perhaps through a new button, or a maybe a property ? Also do we want all folders to be ordered by default ? I think yes, but there may be backward compatibility problems. FWIW here is the monkey patch I'm using to provide ordering functionnality, without any UI. Florent. # derived from OrderFolder by Stephan Richter, iuveno AG. from OFS.ObjectManager import ObjectManager def get_object_position(self, id): i = 0 for obj in self._objects: if obj['id'] == id: return i i = i+1 # If the object was not found, throw an error. raise 'ObjectNotFound', 'The object with the id "%s" does not exist.' % id ObjectManager.get_object_position = get_object_position def move_object_to_position(self, id, newpos): oldpos = self.get_object_position(id) if (newpos < 0 or newpos == oldpos or newpos >= len(self._objects)): return 0 obj = self._objects[oldpos] objects = list(self._objects) del objects[oldpos] objects.insert(newpos, obj) self._objects = tuple(objects) return 1 ObjectManager.move_object_to_position = move_object_to_position def move_object_up(self, id): newpos = self.get_object_position(id) - 1 return self.move_object_to_position(id, newpos) ObjectManager.move_object_up = move_object_up def move_object_down(self, id): newpos = self.get_object_position(id) + 1 return self.move_object_to_position(id, newpos) ObjectManager.move_object_down = move_object_down def move_object_to_top(self, id): newpos = 0 return self.move_object_to_position(id, newpos) ObjectManager.move_object_to_top = move_object_to_top def move_object_to_bottom(self, id): newpos = len(self._objects) - 1 return self.move_object_to_position(id, newpos) ObjectManager.move_object_to_bottom = move_object_to_bottom def manage_renameObject(self, id, new_id, REQUEST=None): """Rename a particular sub-object""" # Since OFS.CopySupport.CopyContainer::manage_renameObject uses #_setObject manually, we have to take care of the order after it is done. oldpos = self.get_object_position(id) res = self._old_ordfold_manage_renameObject(id, new_id, REQUEST) self.move_object_to_position(new_id, oldpos) return res ObjectManager._old_ordfold_manage_renameObject = ObjectManager.inheritedAttribute('manage_renameObject') ObjectManager.manage_renameObject = manage_renameObject def _setObject(self, id, object, roles=None, user=None, set_owner=1, position=None): res = self._old_ordfold_setObject(id, object, roles, user, set_owner) if position is not None: self.move_object_to_position(id, position) # otherwise it was inserted at the end return res ObjectManager._old_ordfold_setObject = ObjectManager._setObject ObjectManager._setObject = _setObject perms = (('Manage properties', ('get_object_position', 'move_object_to_position', 'move_object_up', 'move_object_down', 'move_object_to_top', 'move_object_to_bottom')), ) ObjectManager.__ac_permissions__ = ObjectManager.__ac_permissions__ + perms -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
OrderedFolder is not about having an ordered default view in the management interface. The point is that people want to build menus or web pages that consist of several objects in a folder, using objectValues()/objectIds(). Without OrderedFolder or a similar approach it is very hard to position objects in a menu or on a web site. OrderedFolder has the API to move stuff up or down, insert objects at a given position, etc. ... I consider that VERY useful ... Cheers Joachim ----- Original Message ----- From: "Lennart Regebro" <lennart@torped.se> To: <zope-dev@zope.org> Sent: Tuesday, April 23, 2002 7:13 PM Subject: Re: [Zope-dev] Ordered Folder (was: Speaking of 2.6...)
From: "Florent Guillaume" <fg@nuxeo.com>
Also do we want all folders to be ordered by default ?
I wouldn't want this. I don't know how ordered folder works nowadays, but I want it sorted on name by default.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
From: "Joachim Werner" <joe@iuveno-net.de>
OrderedFolder is not about having an ordered default view in the management interface.
I know that. Still, you do get an ordered default view with OrderedFolder (unless something changed very recently).
Lennart Regebro <lennart@torped.se> wrote:
Also do we want all folders to be ordered by default ?
I wouldn't want this. I don't know how ordered folder works nowadays, but I want it sorted on name by default.
Standard Folders are *explicitly* sorted by name by default, so the fact that the underlying objectValues() returns ordered objects is of no consequence here. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
From: "Florent Guillaume" <fg@nuxeo.com>
Standard Folders are *explicitly* sorted by name by default, so the fact that the underlying objectValues() returns ordered objects is of no consequence here.
So the UI is sorted by default, but objectValues is ordered? Perfect!
--On Wednesday, April 17, 2002 11:48:12 AM -0400 Brian Lloyd <brian@zope.com> wrote:
We've already learned the hard way that the existing SiteRoots and VirtualHostMonsters etc. confuse people. This is partly due to under-documentation, but it is also partly because of the "here, we'll give you several ways to do it!" approach.
True, but...
If there are strong reasons for it to be in the core, then I suspect it would need to be sufficient to be the "official" VH solution and we'd want to deprecate the existing things. That means that it will need to be well documented, and we'll need to produce the needed deprecation docs, transition guides, etc.
Replacing VirtualHostMonster with VirtualHostFolder (via deprecation, etc.) might be a good decision but please remember those of us who need to use the SiteRoot/access rule combo to do more than can be done with the higher level tools. SiteRoots and access rules are primitives that can not be replaced by higher level simple tools. Dan Pierson
At 16.04.2002 15:44 -0400, Brian Lloyd wrote:
I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6
Ivo - I don't have a problem with the spelling of this. I _do_ have a problem with the fact that it (your existing release) actually stores the variable in REQUEST. If it were to store them somewhere more appropriate in the DTML namespace stack, I'd be happy to OK it.
Hm, but the REQUEST is where we want the variables to be set! Otherwise we'd use dtml-let, wouldn't we?. It is my understanding that the dtml-set tag is just REQUEST.set() with sugar on it (and sweet sugar that is!). Changing that semantics might (will?) break existing projects that already use dtml-set (several of mine, FWIW) where the REQUEST is later passed from DTML to e.g. PythonScripts... What Ivo does is *exactly* what I want. What would "somewhere more appropriate" look like? What then would be the difference to dtml-let? I understand that REQUEST.set()/dtml-set is to be used sparingly in general, but in some situations there is no alternative. And it appears to be a widely used Zope(2) idiom as well. Thanks, Stefan -- BLOWFISH n. - Preference for beef
On Wed, Apr 17, 2002 at 12:01:00PM +0200, Stefan H. Holek wrote:
At 16.04.2002 15:44 -0400, Brian Lloyd wrote:
I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6
Ivo - I don't have a problem with the spelling of this. I _do_ have a problem with the fact that it (your existing release) actually stores the variable in REQUEST. If it were to store them somewhere more appropriate in the DTML namespace stack, I'd be happy to OK it.
Hm, but the REQUEST is where we want the variables to be set! Otherwise we'd use dtml-let, wouldn't we?. It is my understanding that the dtml-set tag is just REQUEST.set() with sugar on it (and sweet sugar that is!). Changing that semantics might (will?) break existing projects that already use dtml-set (several of mine, FWIW) where the REQUEST is later passed from DTML to e.g. PythonScripts...
What Ivo does is *exactly* what I want. What would "somewhere more appropriate" look like? What then would be the difference to dtml-let?
I understand that REQUEST.set()/dtml-set is to be used sparingly in general, but in some situations there is no alternative. And it appears to be a widely used Zope(2) idiom as well.
Exactly. dtml-set is just a user-friendly replacement for those horrible <dtml-call "REQUEST.set(..)"> constructs. I could make an optional attribute that makes the tag use the dtml namespace in stead, though I do not know what complications that would have at this moment. Cheers Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/ Consultancy Email: ivo@amaze.nl -=-
I understand that REQUEST.set()/dtml-set is to be used sparingly in general, but in some situations there is no alternative. And it appears to be a widely used Zope(2) idiom as well.
Exactly. dtml-set is just a user-friendly replacement for those horrible <dtml-call "REQUEST.set(..)"> constructs.
Hmm. REQUEST.set is considered evil (it pre-dates dtml-let and other approaches by a long shot), which is why I'm a bit hard-headed about this :) The hope was always that dtml-let would cause REQUEST.set(...) to die out, because it is way too easy for people to get into trouble with REQUEST.set(). The hard-headed part of me would rather that people *have* to type something ugly, as a reminder that they are doing something ugly :^) Having a nice spelling can make it so nice that you don't realize at all that you're walking all over request variables (especially for newbies). That is why I wanted to avoid using REQUEST. I understand your point of view, but we always have to balance the needs of the experienced Zope hacker against the infamous 'steep learning curve' problem that newbies run into. We are trying to be more careful about putting things in the core that have behavior that might surprise people or otherwise make their experience confusing. To me, that is the main decision to be made here. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Hi Brian, Brian Lloyd wrote:
The hope was always that dtml-let would cause REQUEST.set(...) to die out, because it is way too easy for people to get into trouble with REQUEST.set(). The hard-headed part of me would rather that people *have* to type something ugly, as a reminder that they are doing something ugly :^) Having a nice spelling can make it so nice that you don't realize at all that you're walking all over request variables (especially for newbies).
Urm, I don't really agree with this. <dtml-let> is like defining a local variable in python. REQUEST.set is like a global variable, but in Zope terms it only lasts marginally longer. SESSION.set is also global, but lasts even longer I find I want to legitimately store a lot of stuff that belongs in the second case where REQUEST is the perfect vehicle, why is making this smell a little nicer a bad thing? cheers, Chris
<dtml-let> is like defining a local variable in python. REQUEST.set is like a global variable, but in Zope terms it only lasts marginally longer. SESSION.set is also global, but lasts even longer
I find I want to legitimately store a lot of stuff that belongs in the second case where REQUEST is the perfect vehicle, why is making this smell a little nicer a bad thing?
From the Zen of Python: "Explicit is better than implicit".
We've been trying hard to adopt this bit of Zen. If you write REQUEST.set, you can look at it and easily see what is happening. Same with SESSION.set. If you're looking at <dtml-set...> as a newbie to Zope, your first thought is probably "where exactly is this being set?". Who decided that REQUEST was a better place to implicitly set the variable? Why not the SESSION? We are trying to get *away* from the impression that everything in Zope is too implicit and magical :) It's funny to see things run full circle, as now some of the people who have beaten us up the most about too much magic are arguing for brand new and improved magic! :^) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Brian Lloyd wrote:
If you're looking at <dtml-set...> as a newbie to Zope, your first thought is probably "where exactly is this being set?". Who decided that REQUEST was a better place to implicitly set the variable? Why not the SESSION?
Well, given DTML's inherent evilness (;-), what harm ca na little more short hand do? Gimme ZPT anyday :-P cheers, Chris
If you're looking at <dtml-set...> as a newbie to Zope, your first thought is probably "where exactly is this being set?". Who decided that REQUEST was a better place to implicitly set the variable? Why not the SESSION?
Well, given DTML's inherent evilness (;-), what harm ca na little more short hand do?
If DTML is inherently evil, then it is because we have failed to resist a long line of "what harm can it do?"'s. Every step puts you deeper in the dark side. Give in to your hate Luke, together we can rule the galaxy as father and son! Mwuaaahahahahah.... :^) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
At 17.04.2002 10:57 -0400, Brian Lloyd wrote:
From the Zen of Python: "Explicit is better than implicit".
We've been trying hard to adopt this bit of Zen. If you write REQUEST.set, you can look at it and easily see what is happening. Same with SESSION.set.
If you're looking at <dtml-set...> as a newbie to Zope, your first thought is probably "where exactly is this being set?". Who decided that REQUEST was a better place to implicitly set the variable? Why not the SESSION?
Agreed, in this light the set tag turns into a source of confusion. How about a <dtml-requestset>, <dtml-sessionset> pair then? ;-) ;-) <ducking> Stefan PS: Only half joking as the dtml-set syntax is sweet, especially 'optional'... PPS: I know ZPT ;-) -- BLOWFISH n. - Preference for beef
On Wed, 17 Apr 2002, Brian Lloyd wrote:
The hope was always that dtml-let would cause REQUEST.set(...) to die out, because it is way too easy for people to get into trouble with REQUEST.set(). The hard-headed part of me would rather that
dtml-let cannot enable REQUEST.set to die out, because it is a tag that requires nesting. A namespace dtml-set (with some other name so as to not stomp on those people whose code already uses dtml-set) might do more. On the other hand, just switching to ZPT is probably better <grin>. I think I'm going to stay agnostic on whether or not a REQUEST stuffing dtml-set belongs in the core. --RDM
On Wed, 17 Apr 2002 15:27:19 +0200, Ivo van der Wijk <ivo@amaze.nl> wrote:
Exactly. dtml-set is just a user-friendly replacement for those horrible <dtml-call "REQUEST.set(..)"> constructs.
You think thats horrible? It is exactly the same as what you type in a Python Product or PythonScript to achieve the same thing. In my opinion that makes it an icon of clarity compared to most dtml idoms. Do you remember what we had to type to achieve the equivalent of dtml-let, before dtml-let was introduced? That *was* horrible. Toby Dickenson tdickenson@geminidataloggers.com
On Tue, 9 Apr 2002 13:47:49 -0400 "Brian Lloyd" <brian@zope.com> wrote:
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final "plan". I didn't get much (any?) response :(
Hello Brian, just to give some feedback and ask for guidance with the further process. My college, Nils Kassube, has implemented the proposed features, regarding an enhanced MailHost, namely the usage of timeoutsocket in the SMTP-module and the archiving of outgoing mails. We also asked the programmer of timeoutsocket for permission, although the module has a BSD-license. He has no problem with the incorporation of the module into the Zope2 code base. Our current plan is to upload a patch to the collector, so other people, specifically people with a server setup under windows can test this and to send a note to Zope-Dev seeking for feedback. I have checkin privileges and also signed the the necessary papers, so later I can integrate the patch into the code base. Would it be enough to put a documentation in the proposal wiki and is the proposal sufficient? Should we take other actions? We would like to have this incorporated. Please take this mail as a commitment notification :-). Thanks for any answers, with regards, __Janko Hauser -- i.A. Dr. Janko Hauser Software Engineering c o m . u n i t G m b H online-schmiede seit 1994 http://www.comunit.de/ mailto:jh@comunit.de Eiffestr. 598 20537 Hamburg | Germany Fon 040 | 21 11 05 25 Fax 040 | 21 11 05 26
(FYI - I'm changing subject lines to separate the many threads that are going on now...)
just to give some feedback and ask for guidance with the further process. My college, Nils Kassube, has implemented the proposed features, regarding an enhanced MailHost, namely the usage of timeoutsocket in the SMTP-module and the archiving of outgoing mails. We also asked the programmer of timeoutsocket for permission, although the module has a BSD-license. He has no problem with the incorporation of the module into the Zope2 code base.
Our current plan is to upload a patch to the collector, so other people, specifically people with a server setup under windows can test this and to send a note to Zope-Dev seeking for feedback. I have checkin privileges and also signed the the necessary papers, so later I can integrate the patch into the code base.
Ok. I'd like to run the mbox thing by Jim to see if he has any reservations about that (writing to the FS, potential effect on security, etc.) I also need to talk to the License Gods to see if we need anything beyond a verbal OK from the timeoutsocket maintainer.
Would it be enough to put a documentation in the proposal wiki and is the proposal sufficient? Should we take other actions?
We need to get the relevent "official" documentation updated (help system pages and anything in the Zope book that deals with MailHost up-to-date). Chris McDonough is nominally in charge of making sure doc updates are taken care of (chrism@zope.com). You can send doc updates (or pointers to them) to him.
We would like to have this incorporated. Please take this mail as a commitment notification :-).
Thanks. I've updated the plan. Hopefully I can run the mbox stuff by the Zope Pope tomorrow and get back to you then. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Hello Brian. * Brian Lloyd <brian@zope.com> [2002-04-17 20:29]:
Ok. I'd like to run the mbox thing by Jim to see if he has any
The product now uses a Maildir-style approach to deal with concurrent writes. The creation of the file name uses time(), gethostname() and randint() to hopefully create enough "uniqueness" in the names.
reservations about that (writing to the FS, potential effect on security, etc.)
The flooding problem still is not solved. For production sites it's probably a good idea to turn off the backup to prevent DOS attacks. But for debugging it's a valuable tool.
with MailHost up-to-date). Chris McDonough is nominally in charge of making sure doc updates are taken care of (chrism@zope.com). You can send doc updates (or pointers to them) to him.
Okay, I'll write it if the okay from the BDFL is here ;-) Cheers, Nils -- i.A. Nils Kassube Software Engineering c o m . u n i t G m b H online-schmiede seit 1994 http://www.comunit.de/ mailto:nika@comunit.de Eiffestr. 598 20537 Hamburg | Germany Fon 040 | 21 11 05 25 Fax 040 | 21 11 05 26
participants (21)
-
Brian Lloyd -
Chris Withers -
Dan L. Pierson -
Evan Simpson -
Florent Guillaume -
Gary Poster -
Ivo van der Wijk -
Janko Hauser -
Jeffrey P Shell -
Jim Penny -
Jim Washington -
Joachim Werner -
Lennart Regebro -
Mario Valente -
Myroslav Opyr -
Nils Kassube -
Oliver Bleutgen -
R. David Murray -
Stefan H. Holek -
Toby Dickenson -
Tres Seaver