| *** vlado has joined #zope3-dev | 00:00 | |
| jhauser | will this be a german speaking sprint? | 00:02 |
|---|---|---|
| projekt01 | Half of them speak german, I think it depends in which group you are working. | 00:04 |
| jhauser | ok, then it's better if I write it down in english | 00:05 |
| *** sashav has quit IRC | 00:05 | |
| projekt01 | srichter, does your changes (Publisher Response API) affect the jsonserver implementation? | 00:13 |
| *** vlado has quit IRC | 00:25 | |
| *** projekt01 has quit IRC | 00:48 | |
| srichter | projekt01: most likely, but everything has BBB | 01:13 |
| *** yota has quit IRC | 01:27 | |
| *** fdrake has left #zope3-dev | 01:27 | |
| srichter | benji_york: do we want to move testbrowser into Zope 3 trunk? | 01:30 |
| srichter | now that Py 2.4 has been approved | 01:30 |
| benji_york | *has* 2.4 been approved? | 01:30 |
| srichter | yes | 01:30 |
| benji_york | and even if so, has testbrowser been "approved"? | 01:31 |
| srichter | no ;-) but noone has objected | 01:31 |
| srichter | silence is consent :-) | 01:31 |
| GaryPoster | And since it relies on ClientForm et al we have to get that in ZPL if it's going to be in the core | 01:31 |
| benji_york | ok, go for it | 01:31 |
| srichter | and I doubt Jim would veto this :-) | 01:31 |
| GaryPoster | um | 01:31 |
| GaryPoster | stop? | 01:31 |
| GaryPoster | :-) | 01:31 |
| srichter | speak | 01:31 |
| srichter | now or .... ;-) | 01:32 |
| GaryPoster | OK, so you are going to relicense ClientForm et al as ZPL? | 01:32 |
| srichter | no, of course not | 01:32 |
| GaryPoster | (Benji explained to me that we could do that) | 01:32 |
| benji_york | we can, but I don't see the point | 01:33 |
| GaryPoster | (and I believed him :-) ) | 01:33 |
| srichter | we have to very carefully state the requirements inour License file | 01:33 |
| srichter | in fact I would like to experiment a bit with release files later on and try to distribute those modules and packages in a separate file | 01:34 |
| GaryPoster | Ach, I'm late. My concern is that you are going to include testbrowser, which has dependencies on other packages. I'm tentatively ok with that for large, important components, a la lxml, but requiring installation of four packages seems unpleasant. | 01:34 |
| srichter | we can make the choice how we want to do this | 01:34 |
| srichter | I would really like a vendor import section of the repository | 01:35 |
| srichter | then we just use external links, instead in having it in the code | 01:35 |
| GaryPoster | hm, seems like a bigger decision than I have time for now. That's my concern, anyway. | 01:36 |
| srichter | I guess I'll probe Jim tomorrow | 01:36 |
| GaryPoster | eek! | 01:37 |
| * benji_york wonders if srichter is an alien | 01:37 | |
| srichter | :-) | 01:37 |
| srichter | I connect some electrodes to his brain and suck up some knowledge :-) | 01:38 |
| benji_york | l8r all | 01:40 |
| *** benji_york has quit IRC | 01:40 | |
| *** projekt01 has joined #zope3-dev | 01:42 | |
| srichter | projekt01: most likely, but everything has BBB | 01:43 |
| projekt01 | cool | 01:44 |
| projekt01 | btw, do you know how I can delete a object on a view on this object and redirect to the parent container? I run into a location error because the object doesn't exist when redirect is called after delete the object itself. | 01:46 |
| srichter | just call redirect before delete | 01:47 |
| srichter | or forward the request to a view of the container | 01:47 |
| projekt01 | Ok, I try this. I need to do this in a activity where I like to delete the object if I click on the transition "delete" | 01:49 |
| *** J1m has quit IRC | 01:51 | |
| *** GaryPoster has quit IRC | 01:54 | |
| projekt01 | srichter, do you know if I can call "self.participant.activity.workItemFinished(self)" and then delete the object in a workitem's finish method | 01:59 |
| *** bskahan has joined #zope3-dev | 02:04 | |
| projekt01 | srichter, I found a way, get a reference in the view from the parent of the object, delete the object and set the parent again, then the redirect is working. | 02:26 |
| projekt01 | I hope the object get removed from the ZODB since only the view has the reference to the parent and the object | 02:27 |
| *** ignas has quit IRC | 02:29 | |
| *** jinty has quit IRC | 03:11 | |
| *** stub has joined #zope3-dev | 03:25 | |
| *** tiredbones has quit IRC | 03:27 | |
| *** projekt01 has quit IRC | 03:30 | |
| *** __gotcha has quit IRC | 04:13 | |
| *** __gotcha__ has joined #zope3-dev | 04:13 | |
| *** __gotcha__ is now known as __gotcha | 04:13 | |
| *** __gotcha__ has joined #zope3-dev | 05:23 | |
| *** __gotcha has quit IRC | 05:40 | |
| *** roym has quit IRC | 05:54 | |
| *** tvon has quit IRC | 07:21 | |
| *** Jim7J1AJH has quit IRC | 07:33 | |
| *** Aiste has quit IRC | 08:12 | |
| *** tvon has joined #zope3-dev | 08:15 | |
| *** philiKON has joined #zope3-dev | 08:32 | |
| *** j-w has joined #zope3-dev | 09:03 | |
| *** hdima has joined #zope3-dev | 09:19 | |
| *** yota has joined #zope3-dev | 09:28 | |
| *** MJ has quit IRC | 10:02 | |
| *** jhauser_ has joined #zope3-dev | 10:04 | |
| *** mgedmin has joined #zope3-dev | 10:06 | |
| *** jhauser has quit IRC | 10:07 | |
| *** Alef has joined #zope3-dev | 10:15 | |
| *** sashav has joined #zope3-dev | 10:22 | |
| *** tarek has joined #zope3-dev | 10:29 | |
| *** mgedmin has quit IRC | 10:30 | |
| *** projekt01 has joined #zope3-dev | 10:56 | |
| *** mgedmin has joined #zope3-dev | 11:18 | |
| bob2 | hrm | 11:19 |
| *** regebro has quit IRC | 11:22 | |
| *** regebro has joined #zope3-dev | 11:25 | |
| bob2 | I should just be able to register a new browser:page for random built-in classes, right? | 11:25 |
| projekt01 | bob2, random built-in, what's that? | 11:26 |
| bob2 | projekt01: e.g., I should be able to register a new view for zope.app.file.File | 11:27 |
| *** MJ has joined #zope3-dev | 11:27 | |
| projekt01 | of corse, you also can override exisiting views in the override.zcml | 11:28 |
| mgedmin | bob2, yes -- but why would you want to do that instead of registering a view for IFile? | 11:28 |
| projekt01 | ah, you like to register a view on a class not to a interface? | 11:30 |
| *** vlado has joined #zope3-dev | 11:30 | |
| bob2 | hm, putting it on the interface did not work | 11:34 |
| bob2 | hrm | 11:36 |
| bob2 | due to layers confusing me, it seems | 11:36 |
| bob2 | and I'm being confused by how formlib generates edit forms | 11:37 |
| *** regebro has quit IRC | 11:48 | |
| *** regebro_ has joined #zope3-dev | 11:48 | |
| *** stub has quit IRC | 11:55 | |
| *** Aiste has joined #zope3-dev | 12:09 | |
| *** Theuni has quit IRC | 12:19 | |
| *** Theuni has joined #zope3-dev | 12:20 | |
| *** stub has joined #zope3-dev | 12:31 | |
| *** BjornT has quit IRC | 12:53 | |
| *** stub has quit IRC | 12:54 | |
| *** regebro has joined #zope3-dev | 12:55 | |
| *** J1m has joined #zope3-dev | 13:00 | |
| *** BjornT has joined #zope3-dev | 13:16 | |
| *** faassen has joined #zope3-dev | 13:19 | |
| *** BjornT has quit IRC | 13:30 | |
| *** vlado has quit IRC | 13:32 | |
| *** vlado has joined #zope3-dev | 13:32 | |
| *** anguenot has joined #zope3-dev | 13:35 | |
| *** drzoltron_ has joined #zope3-dev | 13:45 | |
| *** vlado has quit IRC | 13:53 | |
| *** BjornT has joined #zope3-dev | 13:53 | |
| *** vlado has joined #zope3-dev | 14:00 | |
| *** vlado has joined #zope3-dev | 14:03 | |
| *** ignas has joined #zope3-dev | 14:13 | |
| *** J1m has quit IRC | 14:15 | |
| *** tiredbones has joined #zope3-dev | 14:18 | |
| *** srichter has quit IRC | 14:28 | |
| *** stub has joined #zope3-dev | 14:31 | |
| *** srichter has joined #zope3-dev | 14:31 | |
| *** ChanServ sets mode: +o srichter | 14:32 | |
| *** zopepaul has joined #zope3-dev | 14:48 | |
| *** d2m has joined #zope3-dev | 14:49 | |
| *** zopepaul has quit IRC | 14:57 | |
| *** niemeyer has joined #zope3-dev | 15:06 | |
| *** drzoltron_ has quit IRC | 15:27 | |
| *** regebro has quit IRC | 15:30 | |
| *** drzoltron_ has joined #zope3-dev | 15:35 | |
| *** benji_york has joined #zope3-dev | 15:35 | |
| *** regebro has joined #zope3-dev | 15:38 | |
| *** drzoltron_ has quit IRC | 15:42 | |
| *** tav has quit IRC | 15:52 | |
| *** mgedmin has quit IRC | 16:10 | |
| *** stub has quit IRC | 16:16 | |
| *** Jim7J1AJH has joined #zope3-dev | 16:18 | |
| srichter | hey everyone | 16:22 |
| srichter | how would you like the switch between twisted and zserver to work? | 16:23 |
| anguenot | hi Stephan | 16:23 |
| srichter | hi | 16:23 |
| anguenot | what do you propose ? :) | 16:24 |
| bob2 | "well" :p | 16:24 |
| srichter | register ZServer server types as ZServer-*, i.e. ZServer-HTTP | 16:25 |
| srichter | make twisted the default by naming them: HTTP, HTTPS, FTP, SFTP, ... | 16:25 |
| anguenot | I'm +1 on this | 16:25 |
| srichter | Have two zope.conf.in files: zope.conf.in (twisted) and zope-zserver.conf.in (ZServer) | 16:25 |
| srichter | so all you have to do is to use zope-zserver.conf.in, if you want to run ZServer | 16:26 |
| bob2 | does this mean all the issues with twisted have been sorted out? | 16:26 |
| *** ignas has quit IRC | 16:26 | |
| *** J1m has joined #zope3-dev | 16:26 | |
| srichter | I think we will also need to install a feature called "zserver" and "twisted" based on the server used, because some pacakges, like the TaskScheduler will only work with Twsited | 16:27 |
| srichter | bob2: well, there haven't been any lately | 16:27 |
| bob2 | hm, I thought it still was a slight speed regression | 16:27 |
| srichter | it's absolutely minimal | 16:28 |
| srichter | the publisher takes much much more time than the server code | 16:28 |
| srichter | the ratio is about 1:100 | 16:28 |
| bob2 | oh, ok, sounds reasonable then | 16:28 |
| srichter | J1m: I just asked: | 16:29 |
| srichter | how would you like the switch between twisted and zserver to work? | 16:29 |
| srichter | J1m: I think I can have twisted well integrated somewhen in the next week or so | 16:30 |
| philiKON | srichter, what was all that about that twisted cannot be hooked up as simple server types because there need to be more zconfig directives for ssl etc. | 16:51 |
| philiKON | ? | 16:51 |
| philiKON | btw, i would rather have one zope.conf file with the zserver section being commented out | 16:51 |
| srichter | well, the conf can be very different | 16:54 |
| srichter | right, so we have SSL info | 16:54 |
| srichter | but really, they are two totally different things | 16:55 |
| srichter | I think we should have two zope.conf.in files to make the difference clear | 16:55 |
| philiKON | hmm ok | 16:55 |
| philiKON | btw, it's not only about the .in files | 16:55 |
| philiKON | concerns instances too | 16:55 |
| srichter | absolutely | 16:56 |
| srichter | I think we will add a mkzopeinstance enhancement that lets you select the server | 16:56 |
| philiKON | good idea | 16:57 |
| *** MrTopf has joined #zope3-dev | 16:58 | |
| *** xenru has joined #zope3-dev | 16:59 | |
| J1m | srichter, let's make this simpler. | 16:59 |
| srichter | ok, I am really open for suggestions | 17:00 |
| J1m | Let's just have once zope.conf.in configured to use twisted in some basic way. | 17:00 |
| J1m | Old zope.conf giles should work and continue to use zserver. | 17:00 |
| J1m | Old zope.conf files should work and continue to use zserver. | 17:00 |
| J1m | Let's do something basic, get it on the trunk, and get a lot more people to try it out before Nov 1. | 17:01 |
| srichter | ok | 17:01 |
| J1m | Lots of people develop against the trunk, so I think it would be exercised well. | 17:01 |
| srichter | ok | 17:03 |
| *** sashav has quit IRC | 17:18 | |
| *** hdima has quit IRC | 17:18 | |
| *** douglasc has joined #zope3-dev | 17:20 | |
| srichter | J1m: do you think that we will permanently switch to twisted? | 17:21 |
| J1m | um | 17:22 |
| J1m | for some definition of switch, yes. | 17:23 |
| J1m | I'm *mainly* interested in switching to WSGI. | 17:23 |
| J1m | I'm happy for twised to be included and be the server used in the default config. | 17:24 |
| J1m | I'd sort of prefer to configure the server and the application separately. | 17:24 |
| srichter | I am just trying to estimate whether it will be worth factoring out common code between zope.app.server and zope.app.twisted | 17:25 |
| J1m | That is, someone shoudl configure their WSGI server. | 17:25 |
| J1m | That is, someone should configure their WSGI server. | 17:25 |
| J1m | The way they do this might not be Zope specific. | 17:25 |
| J1m | If Twisted has a WSGI server, I don't think we should maintain our own configuration mechanism for it, at least not in general. | 17:26 |
| J1m | A wsgo server should have some way of saying how to run an application. | 17:26 |
| *** regebro has quit IRC | 17:26 | |
| srichter | mmh, but then we have to subscribe to Twisted's way of running a server, which is quiet a bit different | 17:26 |
| J1m | Zope, would then have it's own config file. | 17:26 |
| srichter | and involves those tac files | 17:26 |
| J1m | This the price and the benefit of getting out of the server business. | 17:27 |
| srichter | as Itamar put it: It's the difference between running Zope in Twisted or Twsited in Zope | 17:27 |
| srichter | clearly both should be possible | 17:27 |
| srichter | but which one do we support? | 17:27 |
| J1m | Perhaps we can have a *dirt simple^ configuration for the twisted server that people use by default. | 17:27 |
| J1m | If people want to customize anything, however, they should use the configuration mechanism provided by the server. | 17:28 |
| J1m | If they don't like that mechanism, then maybe they'll pick a different server. | 17:28 |
| philiKON | so, in the end, zope.conf will be for zodb config, logging config and, if desired, zserver config. but not twisted config | 17:28 |
| philiKON | ? | 17:28 |
| srichter | we really need to do some tests getting Zope running and then connecting it to twisted | 17:28 |
| J1m | philiKON, basically yes, sans zserver config. | 17:29 |
| philiKON | how would zserver be configured? | 17:29 |
| J1m | It would probably have it's own .conf file. | 17:29 |
| J1m | It would probably use ZConfig. | 17:29 |
| philiKON | a zserver.conf? | 17:29 |
| philiKON | +1 | 17:29 |
| faassen | I'm currently lost in security proxy land, trying to understand when they're there and when they're not. | 17:30 |
| faassen | in a method on an object anything can be done, as 'self' is unproxied, correct? | 17:30 |
| J1m | But let me repeat my goal, fwiw: I don't want to be in the server business. | 17:30 |
| faassen | and if I get objects through, for instance, the catalog, they're also unproxied, correct? | 17:30 |
| J1m | faassen, correct. | 17:30 |
| faassen | okay. | 17:31 |
| J1m | faassen, let's take a step back. | 17:31 |
| faassen | okay, I'm trying to work through the consequences. | 17:31 |
| J1m | if you get an object from a proxied source, the result will be proxied (excluding rocks, of course). | 17:31 |
| philiKON | J1m, yup, exactly. let's get out of the server business. that also means that configuring zope the application server doesn't mean you configure the server at the same time. so, +1 from me on all that | 17:32 |
| faassen | J1m: yeah, I understand that part. | 17:32 |
| J1m | If you get an object from an unproxied source, the source has an option of proxying it for you. | 17:32 |
| J1m | But generally it doesn't. | 17:32 |
| faassen | J1m: how does the source have an option? | 17:32 |
| faassen | J1m: I mean, the source could be programmed so that it does that. | 17:33 |
| philiKON | faassen, it can return proxify(obj) | 17:33 |
| J1m | exactly | 17:33 |
| J1m | self is never poxied. | 17:33 |
| faassen | J1m: and the framework proxies objects when traversing inside ZPT, for one. | 17:33 |
| faassen | J1m: and 'context' on a view is proxied, correct? | 17:33 |
| J1m | (Unless of course, the method chooses to proxy it in the method body.) | 17:33 |
| J1m | faassen, the context of a view or adapter is proxied if the view or adapter adapts a proxied object. | 17:34 |
| J1m | (and if the view doesn't unproxy it's context) | 17:34 |
| J1m | Let's look at how this usually happens. | 17:35 |
| J1m | In Zope 3, we view a URL as an untrusted program. | 17:35 |
| J1m | The publication object that interprets a URL is an "untrustred interpreter". | 17:35 |
| J1m | (Untrusted interpreters are described in some detail in a .txt file in zope.security.) | 17:36 |
| J1m | An untrusted interpreter arranges that any object that comes in is proxied. | 17:36 |
| J1m | So the objects being found via traversal are proxied. | 17:36 |
| J1m | When we adapt them, the adapters adapt proxied objects. | 17:36 |
| faassen | unless it's a trusted adapter, I guess. | 17:37 |
| philiKON | yup | 17:37 |
| philiKON | then the adapter itself is proxied | 17:37 |
| J1m | (An adapter may be defined as a "trusted adapter", in which case, we automatically unproxy it's context. | 17:37 |
| J1m | yup | 17:37 |
| J1m | Now, if a method adapts self, the adapter's context will not be proxied. | 17:38 |
| faassen | anyway, I'm trying to figure out what the consequences are of these basics, I think I got the basics, more or less, but didn't get that the consequences are more involved than I originally thought. | 17:38 |
| faassen | so reasoning about it is harder than I'd like. | 17:38 |
| J1m | Yes. | 17:38 |
| faassen | I mean, if it's so easy to 'accidentally' lose proxies by passing self along to a function, for instance. | 17:38 |
| faassen | (or to an adapter factory, same principle) | 17:38 |
| faassen | and it's also easy to not get them in the first place, by doing a catalog query. | 17:39 |
| faassen | I'm trying to convince myself that this isn't necessarily a bad thing. :) | 17:39 |
| J1m | Yes, this is an issue. | 17:39 |
| J1m | It is potentially a bad thing. | 17:39 |
| faassen | right. | 17:39 |
| faassen | okay, then I think my understanding of proxies is more or less complete. :) | 17:39 |
| J1m | This is why, four our projects, we often provide components or APIs that automatically proxy objects gotten from the intid utility. | 17:40 |
| faassen | so basically you can't really depend on proxies and make all views public. | 17:40 |
| J1m | It has been argued that the intid utility should proxy objects by default. | 17:40 |
| faassen | I mean, you can't depend on context-object security and make all views public. | 17:40 |
| J1m | Not without thinking about it. | 17:41 |
| faassen | but it's also not exactly desirable to make the views protected only and make the content objects nonsecure. | 17:41 |
| faassen | well, it's something that's quite involved and the average programmer won't think about it. | 17:41 |
| J1m | One thing we want, but don't have yet is an untrusted adapter. | 17:41 |
| philiKON | at least i found it more desirable to have no proxies at all and manage security solely on views/adapters than the other way around | 17:41 |
| J1m | A good thing about Z3 relative to Z2 is that it makes it much harder for the programmer to not think about security. :_ | 17:42 |
| faassen | well, but that's also a problem if you want Z3 to be popular. | 17:42 |
| faassen | I may be willing to figure out why something doesn't work and reason about involved proxy interactions. | 17:42 |
| faassen | but not everybody is willing or capable of doing so. | 17:42 |
| faassen | anyway, what I find myself doing repeatedly is.. | 17:43 |
| J1m | anyway, an untrusted adapter would have the property that whenever you proxied an untrusted adapter, it would be rebound to trusted contexts. | 17:43 |
| faassen | reason about why something is not allowed. | 17:43 |
| faassen | conclude I know why ti's not allowed. | 17:43 |
| faassen | and then decide, but I need to do this anyway. | 17:43 |
| faassen | rip off the proxy and continue. | 17:43 |
| faassen | I guess anyone can learn to call this, but then you'll see a lot of voodoo removeSecurityProxy sprinkled through everything. | 17:44 |
| J1m | sure | 17:44 |
| J1m | And this is a problem. | 17:44 |
| faassen | which isn't conductive to security either. | 17:44 |
| J1m | But the alternative seems to be to be less secure. | 17:44 |
| faassen | I mean, I already find myself placing them in many places in the codecase. | 17:44 |
| faassen | codebase. | 17:44 |
| faassen | and I thought they were supposed to be a hack. | 17:44 |
| faassen | but I frequently honestly can't come up with a saner way to do it. | 17:44 |
| faassen | in part that's inexperience, but in part I expect that just is the most straightforward way. | 17:45 |
| J1m | They aren't a hack, but they are a powerful tool that should be used with great care. | 17:45 |
| faassen | would it make sense to have a decorator that rips off proxies from incoming arguments to a method? | 17:45 |
| J1m | as long as you think about it, and preferably include a comment explaining your reasoning, I see no harm in them. | 17:45 |
| faassen | so you can say @trusted | 17:45 |
| J1m | Maybe. | 17:46 |
| *** whiteRook has joined #zope3-dev | 17:46 | |
| J1m | Of course, if overused, that could be a problem too. | 17:46 |
| J1m | After all, you need to be just as careful about remobing security proxies when things are passed to you when it's done automatically. | 17:46 |
| faassen | anyway, the thing that bugs me is that on the one hand the security system gets in my face too oftne. | 17:47 |
| faassen | and on the other hand I discover it has holes. | 17:47 |
| J1m | I'm less worried about adapters because it's much more difficult for untrusted code to fake an adapter call than it is to call methods. | 17:47 |
| faassen | so I do more work than I'd like and still don't know whether my app has security. | 17:47 |
| faassen | anyway, so on the one hand I appreciate the system telling me, hey, cannot do. | 17:48 |
| faassen | and it seems pretty pervasive, but then today I figured out it doesn't do that in some cases. | 17:48 |
| J1m | I am far more concerned about the holes than I am about it getting in my face. | 17:48 |
| faassen | well, I'm concerned about that part too, as I really think a newbie will be lost. | 17:48 |
| J1m | I think we need to think about these, | 17:48 |
| faassen | right. | 17:48 |
| J1m | But there are waaaaaay fewer of these in Z3 than there are in Z2. | 17:49 |
| faassen | so what do you think about the newbie case? | 17:49 |
| faassen | (I think in part the holes get automatically plugged as traversal to something from a view proxies things again, correct?) | 17:49 |
| *** whiteRook has left #zope3-dev | 17:49 | |
| faassen | (or just calling something on a view) | 17:49 |
| J1m | Frankly I'm not sure what to expect of a "newbie". | 17:49 |
| faassen | well, I had to expend quite a bit of brainpower to understand why sometimes I need to remove a proxy. | 17:50 |
| faassen | and I think that some people would be lost, as I think I have a decent amount of programming brainpower. | 17:50 |
| J1m | I'm not too worried about the "self" case BTW. | 17:50 |
| benji_york | I wonder if a "newbe-mode" might be interesting, no (or less) security, but wouldn't bind to any address other than 127.0.0.1 or something | 17:50 |
| faassen | and I also worry that if I feel lazy or tired, I'll just not figure it out and waste time. | 17:51 |
| faassen | benji_york: well, it's more than just newbies. | 17:51 |
| faassen | it's just that reasoning about proxies is quite involved. | 17:51 |
| bradb | "Newbie" can also be written as "someone who wants to get something done on a tight deadline" or "someone who wants to be productive in Zope 3 without having a profound knowledge of the CA". | 17:51 |
| faassen | and I'm not sure that people can be expected to do so. | 17:51 |
| benji_york | I was specifically thinking about scaring people away while evaluating Z3 | 17:51 |
| faassen | bradb: exactly. | 17:51 |
| faassen | benji_york: I think ti's broader than that, as people evaluating Z3 will usually evaluate it by actually trying to build something useful. | 17:51 |
| faassen | anyway, the security system is powerful and helpful, but it's also the one thing I worry most about as reasoning about it is hard. | 17:52 |
| benji_york | faassen, if so they can't be bothered to make sure their useful thing is secure, I don't know what to say | 17:52 |
| J1m | exactly | 17:52 |
| faassen | benji_york: many things are useful without needing complicated security models. | 17:52 |
| benji_york | although we can try to make security easier, I just don't know how much easier it can get | 17:52 |
| faassen | I realize security is complicated. | 17:52 |
| J1m | My experience is that simple applications can generally make security declarations and forget about it. | 17:53 |
| J1m | Simple applications generally don't have to remove security proxies. | 17:53 |
| J1m | At least, that has been my experience. | 17:53 |
| faassen | J1m: that may be correct, I'm not sure. | 17:53 |
| J1m | I would tell people to assume things are proxied and declare permissions appropriately. | 17:54 |
| J1m | With the important and vastly simplifying exception of self. | 17:54 |
| faassen | J1m: I'm not sure what is 'simple'. in the app I'm working with, roles get acquired in some cases (which makes life hard if the object isn't attached to what it acquires from yet), and various role mappings are manipulated by users who cannot be given the permission to fully change the mappings everywhere. | 17:54 |
| faassen | I'm not sure how often such use cases appear in applications. | 17:55 |
| faassen | anyway, I don't really have an answer. | 17:55 |
| J1m | Well, one could argue is that a simple application is one without authenticated users. | 17:55 |
| faassen | I just am worried about it and am thinking about this. | 17:55 |
| J1m | It's a valid and valuable worry. | 17:55 |
| J1m | sometimes I think it would be fun to tale a year off and do research on usability of security systems. | 17:56 |
| J1m | Too bad I have bills to pay. :) | 17:56 |
| J1m | s/tale/take | 17:57 |
| faassen | yeah. well, perhaps a mode that doesn't do much in the way of securit at all would be useful. | 17:57 |
| faassen | I mean, there are many productive web systems that don't bother about worrying about security on the framework level. | 17:58 |
| J1m | Perhaps | 17:58 |
| faassen | like PHP or, I believe, RoR. | 17:58 |
| benji_york | I worry that that would be an "attractive nusance"... | 17:58 |
| benji_york | ...people would build apps in "easy mode", and late in the game try to turn security on and find it insurmountably difficult to get it to work | 17:58 |
| faassen | well, I hope some hybrid model is possible instead, 'security on the outside', for instance. only secure views. | 17:58 |
| faassen | benji_york: yes, that may be a problem. | 17:59 |
| srichter | so we could implement a permissive security policy that simply allows anything to be done | 17:59 |
| faassen | benji_york: in fact, this attractive nuisance already exists. | 17:59 |
| benji_york | security has to be baked in | 17:59 |
| faassen | benji_york: if you log in as a manager, you can do anything. | 17:59 |
| faassen | benji_york: and you *do* only notice security problems if you log in as a non manager. | 17:59 |
| *** efge has joined #zope3-dev | 17:59 | |
| faassen | so perhaps we should remove the system user then. :) | 18:00 |
| benji_york | faassen, so that would be a good recommendation for developers, don't log in as manager (just as you don't test software by running it as root) | 18:00 |
| faassen | benji_york: yes, perhaps we can make it easier for users to get set up that way then. | 18:01 |
| benji_york | at least when logging in, you make a consious choice as who to be, if you're just anonymous you'll see the security problems immediately | 18:01 |
| faassen | benji_york: yes, but that's even easier to accomplish, logging in, than a security policy. :) | 18:01 |
| benji_york | oh, and I wouldn't mention PHP (above) as being a good example of anything relating to security :) | 18:02 |
| faassen | benji_york: I'm not saying it's a good example security wise. | 18:02 |
| faassen | I mean, I think it's clear Zope 3 as a framework is way better at security than most web frameworks. | 18:02 |
| faassen | and on the one hand that's good. | 18:02 |
| faassen | but on the other hand I worry this will put off people early, and I hope we'll get brilliant ideas to mitigate that. | 18:02 |
| faassen | anyway, food for thought. | 18:04 |
| faassen | J1m: thanks for helping with the proxy confusion. | 18:04 |
| andrew_m | funny, just what i needed right now (removeSecurityProxy) | 18:10 |
| *** j-w has quit IRC | 18:13 | |
| *** mgedmin has joined #zope3-dev | 18:15 | |
| *** ignas has joined #zope3-dev | 18:16 | |
| *** tiredbones has left #zope3-dev | 18:17 | |
| srichter | J1m: I think we will need two different startup scripts for twisted and zserver; at least without having some restructuring to do | 18:18 |
| *** bradb has left #zope3-dev | 18:18 | |
| srichter | J1m: z3.py calls specifically zope.app.server.main.main() | 18:18 |
| srichter | twisted uses zope.app.twisted.main.main() | 18:19 |
| srichter | we could have an option for z3.py to select the server | 18:25 |
| srichter | z3.py -s zserver and z3.py -s twisted | 18:25 |
| srichter | thoughts? | 18:25 |
| philiKON | note that this also, actually primarily concerns runzope | 18:26 |
| philiKON | z3.py is just a checkout detail | 18:26 |
| srichter | of course | 18:26 |
| philiKON | runzope is how the enduser will see it | 18:26 |
| philiKON | runzope -s zserver sucks | 18:26 |
| srichter | the end user will do it differently | 18:26 |
| benji_york | srichter, J1m is AFK at the moment | 18:26 |
| philiKON | (it's also in zopectl) | 18:26 |
| srichter | they will select the server during mkzopeinstance | 18:26 |
| srichter | benji_york: any comment? :-) | 18:27 |
| philiKON | srichter, ah, ok | 18:27 |
| philiKON | srichter, so mkzopeinstance could fill in the necessary blanks | 18:27 |
| benji_york | umm, I have to read it first... :) | 18:27 |
| srichter | :-) | 18:27 |
| philiKON | srichter, or, perhaps we have a zserverskel and a twistedskel | 18:27 |
| srichter | :-( | 18:27 |
| srichter | actually this will not work for several reasons | 18:28 |
| philiKON | anyway, why not rename z3.py to zserver.py and introduce a twisted.py | 18:28 |
| philiKON | in the checkout | 18:28 |
| srichter | (that have to do with zpkgtools) | 18:28 |
| benji_york | I think an option to runzope wouldn't be bad, as long as the current "preferred" server is used by default | 18:28 |
| benji_york | I would stay away from multiple skels | 18:28 |
| philiKON | yeah | 18:28 |
| philiKON | i wasn't actually so much talking about multiple skel dirs | 18:28 |
| philiKON | more talking about the concept of having different skeleton scripts and confs for zserver and twisted | 18:29 |
| philiKON | sorry for being confusing | 18:29 |
| benji_york | NP | 18:29 |
| philiKON | anyway, why not rename z3.py to zserver.py and introduce a twisted.py | 18:29 |
| srichter | that is pretty much what I did now | 18:29 |
| srichter | though it seems a bit lame | 18:29 |
| benji_york | well, you don't really want to run zserver or twisted, you want to run zope under a particular HTTP server | 18:30 |
| srichter | right, this will come later | 18:31 |
| philiKON | yeah, but won't people know what we mean? | 18:31 |
| srichter | right now we manage the server from within Zope | 18:31 |
| srichter | we have to turn this around | 18:31 |
| * mgedmin wonders whether 'serverengine twisted|zserver' in zope.conf would work or not | 18:31 | |
| srichter | however, this is a bit of work, since we have to understand the startup and run code for every supoprted server | 18:31 |
| srichter | mgedmin: definitely with some abstraction | 18:32 |
| srichter | mgedmin: but it would involve a day of work or so | 18:32 |
| benji_york | how about a somple server.conf that says what server to use and use .tac files for twisted and zserver.conf for zserver (removing neccesary things from zope.conf perhaps) | 18:34 |
| benji_york | too many conf files? | 18:34 |
| philiKON | benji_york, that's sort of what jim proposed | 18:34 |
| philiKON | leave server config to whatever mechanism the server has | 18:34 |
| philiKON | zope.conf would just deal with zodb and logging conf | 18:34 |
| benji_york | yep | 18:34 |
| philiKON | i'm +1 | 18:34 |
| srichter | this is a huge change | 18:35 |
| srichter | because very established patterns will be removed and changed | 18:35 |
| benji_york | yep, so is supporting more than one server | 18:35 |
| srichter | I am +1, but the above is a risk to consider | 18:35 |
| benji_york | definiately | 18:36 |
| projekt01 | why not load additional config from the main conf file, like apache does it for its virtual hosts? | 18:37 |
| * srichter just noticed that the twisted FTP code is broken :-( | 18:37 | |
| projekt01 | so you have a central file where you can check the config | 18:37 |
| srichter | projekt01: this does not solve the problem | 18:38 |
| projekt01 | Ok ;-( | 18:38 |
| srichter | the question is really, if we want to switch to Twisted's server setup mechanism or use a similar one to the one we have now (and that is currently implemented) | 18:39 |
| *** sashav has joined #zope3-dev | 18:39 | |
| srichter | I really like our conf system | 18:39 |
| projekt01 | me too | 18:39 |
| srichter | it is much more firendly to the admin | 18:39 |
| srichter | tac files are python | 18:39 |
| srichter | and they would be fairly big, I think | 18:40 |
| mgedmin | as a random unix admin, I am familiar with plain text config files, and mysterious twisted inventions like *.tac/*.tap/whatever confuse me | 18:40 |
| mgedmin | maybe that's because I never took the time to read the documentation or try them out ;) | 18:40 |
| srichter | but as sysadmin you should not be required to learn the specific conf format for every software you run | 18:41 |
| srichter | and learn a language on the side | 18:41 |
| srichter | okay, I think I just convinced myself that keeping conf files has a lot of value | 18:42 |
| srichter | so the remaining question is how we determine the server engine to use | 18:42 |
| srichter | to summarize: | 18:42 |
| *** regebro has joined #zope3-dev | 18:43 | |
| srichter | 1. Use different startup scripts in SVN and have somewhere an option for releases, such as mkzopeinstance | 18:43 |
| srichter | 2. Use serverengine option in zope.conf | 18:43 |
| srichter | I am fine with both approaches; I would just like to decide on one :-) | 18:43 |
| srichter | gotta run | 18:48 |
| *** srichter has quit IRC | 18:48 | |
| *** vlado has quit IRC | 19:00 | |
| *** niemeyer is now known as nie_lunch | 19:04 | |
| mgedmin | it would be hard to change the decision later on if you determine it at mkzopeinstance time | 19:11 |
| mgedmin | so I'm for (2) | 19:11 |
| *** MJ has quit IRC | 19:22 | |
| *** vlado has joined #zope3-dev | 19:28 | |
| *** MrTopf has quit IRC | 19:34 | |
| *** douglasc has quit IRC | 19:39 | |
| *** tvon has quit IRC | 19:41 | |
| *** tvon has joined #zope3-dev | 19:42 | |
| *** benji_york has quit IRC | 19:50 | |
| *** benji_yor1 has joined #zope3-dev | 19:51 | |
| *** nie_lunch is now known as niemeyer | 19:51 | |
| *** benji_yor1 is now known as benji_york | 19:51 | |
| *** fdrake has joined #zope3-dev | 20:17 | |
| benji_york | hi fdrake! | 20:17 |
| fdrake | you benji! | 20:18 |
| benji_york | someone set us up the bomb! | 20:18 |
| *** faassen has quit IRC | 20:18 | |
| philiKON | hi fdrake | 20:18 |
| fdrake | hey philiKON | 20:19 |
| *** tav has joined #zope3-dev | 20:22 | |
| *** alga has joined #zope3-dev | 20:31 | |
| *** tiredbones has joined #zope3-dev | 20:51 | |
| *** bskahan has quit IRC | 20:52 | |
| *** bskahan has joined #zope3-dev | 21:14 | |
| *** tarek has quit IRC | 21:15 | |
| *** zopepaul has joined #zope3-dev | 21:15 | |
| *** regebro has quit IRC | 21:16 | |
| *** MJ has joined #zope3-dev | 21:19 | |
| *** jinty has joined #zope3-dev | 21:27 | |
| *** SureshZ has joined #zope3-dev | 21:44 | |
| *** efge has quit IRC | 21:48 | |
| *** srichter has joined #zope3-dev | 21:49 | |
| *** ChanServ sets mode: +o srichter | 21:51 | |
| srichter | J1m: how much longer are you at work? I am about to leave school, then it will be better to talk | 21:54 |
| mp | http://wiki.zope3.pl/static/zope-apidoc/++apidoc++/Code/ ;] | 22:00 |
| mgedmin | nice and fast | 22:01 |
| mp | wget | 22:02 |
| mp | static | 22:02 |
| srichter | wow, how much memory does it take up? | 22:02 |
| mp | however, it *was* fast when I downloaded it | 22:03 |
| srichter | I did this once and it used a lot of space for the menu options | 22:03 |
| mp | btw, it would be nice to improve apidoc, so it can really generate static pages | 22:03 |
| srichter | I am working on a static version for APIdoc where the menus are JS-based | 22:03 |
| mp | make it downloadable with wget - it would be pretty usable | 22:04 |
| mp | relative links etc | 22:04 |
| srichter | its on my 3.2 list;l however I would appreciate some help any time :-) | 22:05 |
| srichter | the main outstanding issues are: JS version of interface search (easy I think) and JS version of menus | 22:05 |
| benji_york | srichter, J1m is AFK, but will be back in a minute | 22:06 |
| *** zopepaul has quit IRC | 22:06 | |
| srichter | ok, I will go home now and be back online shortly | 22:06 |
| mp | http://horpah.hell.org.pl/apidoc-css-link.patch.txt | 22:07 |
| mp | ;) | 22:07 |
| *** deo has joined #zope3-dev | 22:07 | |
| srichter | please check this in | 22:08 |
| mp | how? | 22:08 |
| *** srichter has quit IRC | 22:08 | |
| mp | who? | 22:08 |
| mgedmin | mp, how much dik space does it eat? | 22:09 |
| mp | 95Mzope-apidoc | 22:10 |
| mp | 8,8Mzope-apidoc.tgz | 22:10 |
| J1m | mp, wget has an option to convert absolute links to relative links. | 22:10 |
| mp | argh | 22:10 |
| mp | 195Mzope-apidoc | 22:10 |
| mp | 8,8Mzope-apidoc.tgz | 22:10 |
| mp | J1m: I used that, but I would be nice to be able to just download pages and have them fully functionall.. there could be even option to get reference as single big html file or page-per-chapter - just like lot's of gnu and open source sofware has | 22:12 |
| mp | http://www.gnu.org/software/gawk/manual/ like here | 22:12 |
| mgedmin | sometimes I wish zope had @@relative_url in addition to @@absolute_url | 22:13 |
| mp | hm, is it that difficult? | 22:13 |
| mgedmin | the url of the current page is available in the request, so it should be possible | 22:14 |
| mgedmin | take the absolute url, see if there's a common prefix, rip it out, perhaps add some ../ | 22:14 |
| J1m | Not a common prefix. | 22:14 |
| mp | in simple version it should attach ../ to get parent of both objects, then get down to target by appending ids and '/'-s | 22:14 |
| J1m | The current page's base would need to be a prefix of the desired url. | 22:15 |
| mgedmin | J1m, is your new test runner merged to the trunk? | 22:15 |
| mp | so, there should be "@@almost_working_relative_url_not_guarantees_use_at_our_own_risk" :> | 22:16 |
| mp | because usually described behaviour might be enough :) | 22:16 |
| J1m | mgedmin, not yet. | 22:18 |
| *** alga has quit IRC | 22:21 | |
| *** mgedmin has quit IRC | 22:21 | |
| *** xenru has quit IRC | 22:31 | |
| SteveA | J1m: what should publishTraverse do if the name doesn't go anywhere? | 22:35 |
| SteveA | should it raise UrlNotFound (or whatever it is called) | 22:35 |
| SteveA | ? | 22:35 |
| J1m | Yes | 22:36 |
| SteveA | i just had it reported to me that in the zope3 we're using for launchpad, if you define a page in zcml that uses a class and attribute | 22:36 |
| SteveA | and you go to a URL that is .../thatview/somethingthatisnotthere | 22:37 |
| SteveA | you get a 500 internal server error, rather than the expected 404 | 22:37 |
| J1m | sounds like a bug | 22:37 |
| SteveA | so, i guess that can be fixed in the publishTraverse that is used in the constructed classes for the page / view directives | 22:37 |
| J1m | yup | 22:37 |
| SteveA | okay. do you know if it needs fixing elsewhere than the trunk? | 22:38 |
| J1m | hm | 22:38 |
| J1m | It would br nice to fix it on the 3.1 branch. | 22:38 |
| J1m | as well | 22:39 |
| *** tvon has quit IRC | 22:42 | |
| *** srichter has joined #zope3-dev | 22:49 | |
| *** ChanServ sets mode: +o srichter | 22:50 | |
| srichter | benji_york: is Jim on his computer? | 22:51 |
| benji_york | not ATM, but will BRB | 22:51 |
| srichter | ok | 22:51 |
| *** ignas has quit IRC | 23:01 | |
| *** tiredbones has quit IRC | 23:16 | |
| mp | srichter: if you asked *me* to check in, then I don't have write access to repo | 23:27 |
| srichter | mp: have you asked for write permssion? :-) | 23:32 |
| srichter | mp: J1m can give you access once you signed the contributor agreement | 23:32 |
| *** projekt01 has quit IRC | 23:33 | |
| *** projekt01 has joined #zope3-dev | 23:34 | |
| *** benji_york has quit IRC | 23:34 | |
| srichter | J1m: should the logging setup ZConfig stuff be part of the server or the application? | 23:35 |
| srichter | we have eventlogs and access logs; clearly the latter is server, but what about the eventlog? | 23:35 |
| srichter | is it even used? | 23:35 |
| *** sashav has quit IRC | 23:39 | |
| fdrake | the event log is certainly used | 23:41 |
| fdrake | that's where all the interesting stuff goes :-) | 23:41 |
| srichter | so should it be part of the app server or the network server setup? | 23:42 |
| fdrake | that's a good question still | 23:42 |
| fdrake | the way they both use the logging package is important, but I don't think it bounds the answer in any way | 23:43 |
| J1m | The event log should go in the app, imo | 23:44 |
| srichter | mmh, the problem is that I am splitting up the app server configuration from the network server configuration | 23:44 |
| srichter | ok, that's what I have now | 23:44 |
| fdrake | so we need to be careful to document the way the logging package is used by the different parts, so that a server will know what it needs to do to live nicely together with the other logs | 23:45 |
| srichter | not really | 23:46 |
| srichter | because the server config imports the app one | 23:47 |
| srichter | I just need to split it so that in case we only want to bring up the app, we have only the subset to deal with | 23:47 |
| srichter | ohhh, now I see what you are saying | 23:47 |
| fdrake | it's not a problem, it's just a documentation requirement | 23:47 |
| srichter | I guess it will be fine, since we use the standard logging mechnism for Python | 23:47 |
| srichter | yep, I agree | 23:48 |
| fdrake | so it probably needs a collector issue for now, unless you're ready to write the doc | 23:49 |
| fdrake | I can write it, but not right now. | 23:49 |
| srichter | I'll keep it in mind for now :-) | 23:50 |
| *** tvon has joined #zope3-dev | 23:50 | |
| srichter | fdrake: how can I define an app.xml that is a schema and that I can also import into another XML file? | 23:52 |
| *** niemeyer is now known as nie_coffee | 23:56 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!