From: "Matt Behrens" <matt.behrens@kohler.com>

Christian Theune wrote:

...

Well I saw the cookie crumbler wish has been added to the list already, and (as i tested it out this moment) don't see what exactly needs to be done than adding it by default to the root userfolder. Well, probably some facelifting to the default login, thats not urgent in any way but if wished i would do that.

Well, as far as "least-intrusive", CC loses some points by not being compatible with some of the user folders that do their own cookie auth, although that's arguably not CC's fault.

Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking. And now there is a possible inclusion of another product (CC) that might conflict with other products' cookie functionality. Instead of locking up users with a particular implementation of a solution to a general problem, why not present an API for a) session management and b) cookie management, and then present default products that use these API's to provide solutions? This way it will not be hard to replace both session management and cookie management with other products. Any one else think that this might be a worthwhile idea? If so, I can offer time and effort and my limited knowledge of zope to make this possible. /dario

Christian Theune wrote:

Hmm. I didn't get an answer right now (well i don't find the question again too) if the cookie crumbler would interfere subfolders (distor through acquisition) or would only be active on a "sibling" userfolder, which he is "watching".

I'm really not sure. I imagine it could be troublesome.

Which makes me think of another point. I haven't used Zope 2.5.1 yet, but I understand from some of the traffic on the mailinglists that some have wanted to disable the session tracking/session management beause it interferes with the solutions they allready use for session tracking.

This is possible now. The sessioning solution is very general and everything is parameterized and can be disabled. AFAIK, the complaints I've seen so far have been attributable to folks just misunderstanding the management screens and thinking that the default sessioning configuration is immutable. - C

Well. (This answer could also be posted a bit up the thread) I think we see that Cookie Crumbler may not be the solution to what i originally itended - the availability of cookie based authentication in the standard userfolder. Due to its problems, it seems as if it would be best, to extend the first userfolder again (currently a userfolder on the api has no idea about different authentication methods at all, or am i wrong?) but this would break the api - which changed in 2.5 afairk already - again, which i do not desire just for the sake of proper logout of management interface / cookie logins ... but i still believe it would be good to be there. Greetings Christian On Tue, Mar 05, 2002 at 03:31:50PM -0500, Trevor Toenjes wrote:

I like the idea of adding cookie auth to the API. The user product choices are convoluted and I think the community would benefit from adding standard capability to the core.

Adding to that... my priority would be to extend acl_users folder to allow for built-in storage of additional user properties beyond username/password. Yes, there are user products that do this to a point, but an API that allows you to simply do it in ZODB would be ideal.

Maybe someone more familiar could determine a "best of" integration that addresses acl_users folder extensibility and security to add this to Z2.6.

-Trevor

-- Christian Theune - ct@gocept.com gocept gmbh & co.kg - schalaunische strasse 6 - 06366 koethen/anhalt tel.+49 3496 3099112 - fax.+49 3496 3099118 mob. - 0178 48 33 981 reduce(lambda x,y:x+y,[chr(ord(x)^42) for x in 'zS^BED\nX_FOY\x0b'])

Well, lets fix one of those things. :-) The "Enhanced virtual hosting" part of the "Enhanced virtual hosting / local roles blacklist" entry is really the same as the "Virtual Host Folder" further down, so that has a volunteer. And we at torped (That is me and Johan Carlsson) could do the "Local roles blacklist" part.

We are not contributors yes, but Paul E suggested that we'd become that to fix some bugs that we want fixed in 2.5.1, and then we could do this also.

Great - I've update the proposed feature list. Brian Lloyd brian@zope.com Software Engineer 540.361.1716 Zope Corporation http://www.zope.com

I don't know OrderedFolder very well but it'd be very useful in several of my projects, so I can volunteer a bit of time in helping to get it in Zope 2.6 as well.

I'd rather see that you used your time to put Formulator into 2.6 :-P /Magnus

Hi!

That is Stephan's product, not mine, and it *may* have some issues in certain OS distributions (based on my experiences and another user's). So, it cannot be added itself without some work--further testing work if nothing else.

What kind of problems does OrderedFolder have? There is no OS-specific code AFAIK. It is possible that there are browser-specific issues in the frontend. But those would be easy to fix ... Joachim

At 10:40 AM 3/6/2002 -0500, you wrote:

From: "Joachim Werner" <joe@iuveno-net.de>

...

Hi!

What kind of problems does OrderedFolder have? There is no OS-specific code AFAIK. It is possible that there are browser-specific issues in the frontend. But those would be easy to fix ...

Hi :-)

In certain circumstances, if you install OrderedFolder (0.5.1 is last I checked) without ZBabel, *all* of the buttons on the main OrderedFolder management page will have "None" for their label. I have not had time to narrow down what those "certain circumstances" are, but my iMeme FreeBSD Zope does exhibit the error, and my Windows box does not. When I have a second to breathe I'll try it on Linux with a completely clean Zope install. One other beta tester of VirtualHostFolder reported this error with OrderedFolder; I have not gathered information from him as to his OS etc. It may also occur only when you configure OrderedFolder in a certain way.

My beta tester reported that if you installed ZBabel the problem went away. I have not tested this on my FreeBSD Zope.

So--who knows. This needs some testing, if nothing else. I'll get around to it when I can, because Stephan said he was unable to replicate the error. Obviously, I didn't exactly give the most complete bug report ever. It may be an interaction problem or anything. It looks like I won't have much of a chance to look at this myself until next week.

If OF will make it in the core, the ZBabel stuff will be taken out of it in anyway, since no part of Zope has something like that in it. I am also tempted to say that only the ordering module should go in (maybe the limit as well), since other functionality seems too specific. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

Stephan Richter wrote:

If OF will make it in the core, the ZBabel stuff will be taken out of it in anyway, since no part of Zope has something like that in it. I am also tempted to say that only the ordering module should go in (maybe the limit as well), since other functionality seems too specific.

Regards, Stephan

I am afraid I must second this opinion. We recently looked at OrderedFolder, thinking to subclass it to produce our Slideshow product. The idea was to make a lightweight web-based replacement for PowerPoint where you can define the order of the slides and can hide/show them individually. We found that it was actually easier to create our own "OrderedFolder" base class and subclass it rather than use OF because of the extra functionality we did not want. Of course, the extra functionality is probably really useful for some people. My vote would be to include _some_ additional functionality like defined orderings in the Zope3 core, and keep OF as a third party extension product which people can use or not. The Zope3 version of OF would then be simpler, as it would only have the remaining functionality (like "reverse" acquisition, setting a max limit on number of items, etc.) To summarize, I would like to see regular Zope Folders enhanced to optionally have some notion of type ( a la Brian's Zope 2.6 proposal "Object Type Assocation And Death To index_html" ) and basic ordering I am willing to help out. I would love to see this functionality in 2.6 and carry it forward to 3.0... my 2c, --Craeg

Stephan Richter wrote:

...

I am afraid I must second this opinion. We recently looked at OrderedFolder, thinking to subclass it to produce our Slideshow product. The idea was to make a lightweight web-based replacement for PowerPoint where you can define the order of the slides and can hide/show them individually.

Actually, there SmartWizard (of course built with OF), whcih can be used for Slideshows. I used it for all my talks last year.

For some reason we missed that one :-( Of course, we also wanted functionality like selectively hiding slides (that way you can have lots of slides in a standard slideshow and choose subsets for a particular presentation). Still, the Products _are_ quite similar. We might be able to collaborate, but I suspect the Zope-2 architectural limitations will make it pretty difficult. For example, we have three products that are related by inheritance, and even though _we_ wrote all of them, it was interesting how much extra work it was to make them extensible in this way. With the Zope-3 architecture it would be _much_ easier.

...

We found that it was actually easier to create our own "OrderedFolder" base class and subclass it rather than use OF because of the extra functionality we did not want.

Really? You should just have used OrderedObjectManager as base class.

Are you referring to the latest (0.4 IIRC) release? We did our work before that came out...

...

I am willing to help out. I would love to see this functionality in 2.6 and carry it forward to 3.0...

Ordering and the Limit code is already in the Zope 3 core. The advanced Folder version there is know as LoadedFolder.

Excellent! I think Zope-3 anticipation is building to a fever pitch.... ;-) --Craeg

While we are asking, I have two things that I would consider valuable additions to Zope 2.6: 1. UserSniffer. Currently an External Method, but has functionality that should be available OOTB to assist making those (horrors!) browser-dependent hacks. It has other uses, too, like explaining to clients that their browser is five years old and needs the free upgrade that is available. 2. Support for HTTP_X_FORWARDED_FOR. Many (most?) of us run zope behind Apache ProxyPass or Squid, and the Zope logs therefore save the ip address of the proxying machine rather than any semblance of where the client browser is. I realize that other proxies do not always follow the rules, etc., etc., but I think that using HTTP_X_FORWARDED_FOR if not null would be better than a log full of 192.168.1.1. Apologies if these have already been discussed under another heading. -- Jim Washington

Hi all -

1) If the projects for which I have volunteered are accepted as a goal for Zope 2.6 then I have some work cut out for me, and I'd like to try to schedule the necessary time intelligently and early. Any ideas on when the "grocery list" will be evaluated?

I think that this needs to happen Real Soon. I propose that this friday (the 15th) is the deadline for adding/volunteering for the 2.6 plan. After Friday, we need to cull the list to something managable (there is quite a lot there now). I further propose that any item on the list that does not have a sponsor (someone who has explicitly signed up to see the feature through, incl. associated tests, documentation, API help etc.) by Friday gets dropped from the plan. The working timeline for Zope 2.6 is to have an alpha out in about 6 weeks (beginning of May). Things whose sponsors don't think they can make that timeline should probably come off of the 2.6 plan (though they certainly can continue the projects, they would just go into a later release). So let's see what the list looks like after Friday when we know what is unchampioned or will not fit in the timeframe. Early next week, we should plan to debate the remaining items and finalize the list. It would be great if those who have volunteered to lead 2.6 projects could contact me with a rough est. of how long you think it will take and what collateral tasks there will be (any updating of existing documentation, new docs / API help and unit tests). I'll volunteer to update the plan in a little more detail.

2) If we had a brief Zope 2.6 style guide, similar to the Zope 3 stuff, that would be cool. In particular I'd like to be able to see "state of the art" 2.x ZC unit test approaches. Just point to a canonical example in Zope 2.5 or CMF, maybe?

I think any of the /tests directories in the Zope core are decent examples. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

Florent Guillaume wrote:

Okay, I'm a bit late but I'd like to integrate what's currently in NuxUserGroups, a bit updated maybe.

http://www.zope.org/Members/nuxeo/Products/NuxUserGroups

There will be a merge conflit with Lennart's Local roles blacklists, it it's chosen for 2.6, but I'm familiar enough with both code sets to manage the merge.

I'm adding this proposal to the wiki.

I do recall that we looked at NUG as XUFers at at one point, and akm said it looked like it'd be compatible, although we still needed UI for groups in XUF. Nobody has done this, incidentally. :-) I'm not convinced that it'll go so well with other user folders. My gut feeling is that while groups are a very, very good thing (we NEED them here), and I'd love to see them in Zope 2, I think the issue of compatibility with all the other user folders out there is going to be a huge sore spot. So, -1, unless you can prove to me that every user folder on zope.org that hasn't already been obsoleted due to Zope changes will also work with NUG integrated (and the unfortunate fact that everyone probably has to change UI probably makes that a non-issue.) This coming from a guy who really wants groups. :-/

I also want groups! But I want a different kind of groups, that I call "workgroups" just to distinguish them from all other types of "groups". :-) I don't know if it's possible implement this compatibly in 2.x, and I can't judge if there is any problems in implementing one type of groups in 2.x and then switching in 3.x. And of course, I'm worried that implementation of groups in 2.6 will lessen the possibilities of getting workgroups into 3.x. :-) A workgroup is a set of users, just like I understand that NuxUserGroups are. But you set up a workgroup just like you would set up the local roles for a folder, ie, you do not only assign users to the workgroup, *you also assign roles to them within this workgroup*. When setting up a workgroup you don't get access to anything but the workgroup itself. But, you can then add any number of workgroups to a Zope folder, and the users in that workgroup would get the roles they were assigned in the workgroup to that folder. That way you still get the grouping and indirection that you get from otehr grousp, but you also get a greater automatic granularity in that grouping. So, in technical terms a workgroup is macro of role definitions. When you add a user to the workgroup and give him a Reviewer role, he will get the Reviewer role at all the folders where the workgroup is added to the workgroup list. The workgroup "Boss" will get the "Boss" role in all the places where this workgroup is added. With normal grouping, you typically have one group per department, and give that department access to a couple of parts of the database. Then you have a group of the Bosses that have more access. But usually this means that all the Bosses have Boss access everywhere, which is not necessarily what you want. So, even if it is very tempting to let Florent implement the local roles blacklist instead of doing it ourselves :-), I'd rather wait for workgroups than standard groups. In any case Johan and me would be very happy to help Florent and the others at Nuxeo implement it groups and blacklists. Best Regards Lennart Regebro Torped Strategi och Kommunikation AB

Jim Penny <jpenny@universal-fasteners.com> wrote: [...]

I needed a generalization of this scheme (and so ended up writing my own User Folder).

We manufacture parts which are controlled by second parties, but bought primarily by third parties. I will call these parties Manufacturer, Brand Owners, and Contractors.

I now have two kinds of administrators, and two kinds of users. There are unrestricted administrators and users. Since this really is enforced only at the user folder level (normal zope machinery is used elsewhere), a quick description is that an unrestricted administrator may create, modify or destroy any user or Brand Owner Name, and may associate any list of Brand owner names with any user. Any unrestricted user has a flag designating him as such and it is expected that application code check the flag and permit access to the contents held for Brand Owners.

Restricted Administrators may create new users, modify users, or delete (some) users. However, any user they create may have only a subset of their brand owner name list (and their normal zope permissions). They may remove any of their brand names from a user that has one or more of the brand names under their control. They may delete users that have brand names only under their control. They may also create other administrators, subject to the subset restictions.

Restricted Users have a brand list associated with them. Application logic can use this brand list to filter content.

The restricted administrator is a big deal to us. If this takes off, we will not be able to properly control the set of Restricted Users (at Brand Owners and Contractors). Failure to do so could lead to legal exposure, so by creating Restricted Administrators who are Brand Owners, the contrl (and thus most of the legal exposure) can be shifted back to the Brand Owner.

This screams of ACLs for user management... I'm having the need too, in the context of CMF. I ended up writing an additional service (portal_directory) that has a complex set of ACLs to mediate access to the user folder. Some code will be released soon. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com

On Wed, Mar 20, 2002 at 07:01:13PM +0100, Lennart Regebro wrote:

From: "Jim Penny" <jpenny@universal-fasteners.com>

...

I now have two kinds of administrators, and two kinds of users.

An interesting case. If I understand it correctly, with our workgroups scheme,the restricted administrators would have administration rights on a workgroup. They would then be able to create users and add them to the workgroup they manage, but they wouldn't be able to give the users any priviligies outside the workgroup, and hence the new users priviligies would be limited to whatever priviligies they can get through the workgroup.

Right, although they may have adminstration priveleges on a set of workgroups. To give a motivation, consider a large company that has parallel design groups. The groups are intentionally kept in the dark about the other groups' work. Some companies do this to get a variety of choices to base the final decision on. Just to label them, call them Green, Blue, and Red teams. In this case, I might delegate an administrator who has authority over all of these teams, i.e, the administrator can (partially) control users or other administrators who have a subset of (Green, Red, and Blue) in their group list. The administrator, being a busy fellow himself, might create a Red administrator, who can (partially) control users or other adminstrators that have Red in their group list. Now, I am not really deep into modifying Zope core code at this point. The list of acceptable groups is available for any given user. The application programmer handles authorization and presentation. We have to have this for both reasons of scale and delegation of authority. Some, even many, of the design teams themselves use sub-contractors. We have no way of knowing the contractor's day-to-day relationships with the groups, and prefer not to know. Also, we are in a somewhat incestuous industry, and people move from company to company. While they obviously have what is in their head at the time of the move, we do not wish to give them knowledge of future plans. There are interesting policy decisions to make. Should an administrator be allowed to grant workgroup access to a pre-existing user? Can an administrator change a pre-existing user into an administrator? What does delete mean if the use has workgroups that the administrator does not control? Can the administrator see what workgroups the user has? Jim

From: "Florent Guillaume" <fg@nuxeo.com>

No no no ! With NUG the Roles added to a group are still added at the local role level, which means that the 'bosses' group only has a Boss role where you want it.

Yes, of course. But what I was aiming at is that all the Bosses have Boss right at all the places where the Boss group have rights. There is no way to differentiate within one group.

I really think that my model can be used for what you do.

Sure it can. What you have to do is that for each role that you want within a workgroup you will have to create one group. So if you have ten departments, and you have five roles within these departments (f ex authors, reviewers, HR, CR and Bosses), you just create 50 different groups, one group for each department and role, and assign the permission for each of these fifty roles at the correct locations in the hierarchy. In a nightmare scenario, each department should have exclusive access to say 2 areas, and access to one shared area. This means that you need to do 50*3 = 150 group to roles mappings. So yes, you can. It's just more work. Just as if this was done without any groups at all, you would have to add each user to the local roles to each place. Say 15 users in each department times ten departments is 150 users times 3 locations gives you 450 separate assignments. No fun. With workgroups you create ten workgroups. Within each workgrup you assign users to their respective roles. You then add the workgroups to the correct places in the hierarchy. It also opens for the possibility to assign workgroup managers that can create users and add them to their groups without having any other manager rights (although this could be added later to make it easier to implement).

By the way, have you reviewed the use cases for workgroups that I put in http://www.zope.org/Members/nuxeo/Products/NuxUserGroups/README.txt ?

Now I have. :-)

From: "Florent Guillaume" <fg@nuxeo.com>

Then it's simply :-) a matter of user interface. There's also the question of what permissions are needed to modify a workgroup of course.

Does this match what you want ?

Yeah, I think so.

Looks quite feasible to me, and I think it can be done pretty independantly of the user groups I propose.

Hmm, yeah, thats true, it would be possible to have both, even though they aim to solve the same problem. Wouldn't it be a bit confusing to have both? Too may different ways of giving a person a role.