Ticket #9756 (closed PLIP: wontfix)
Plone should not force switching the Zope root acl_users to a Pluggable Auth System.
Reported by: | davisagli | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.x |
Component: | General | Version: | 4.1 |
Keywords: | Cc: |
Description (last modified by davisagli) (diff)
Currently when a new Plone site is created, the Zope root's acl_users is converted from a basic user folder into a Pluggable Authentication System. However, that doesn't happen automatically if you mount a database with an already existing Plone site. That can lead to hard-to-track-down errors (often AttributeError: getGroups). The current recommendation for dealing with this is to simply add and then delete a dummy Plone site to trigger the acl_users conversion.
It would be great if we could have PlonePAS do this automatically when a new mountpoint is mounted, either via an event handler or by monkeypatching Products.ZODBMountPoint.
Update: As MJ pointed out below, "It should be easy enough to fix the PAS folder in Plone itself to support a non-PAS top-level acl_users as a users source instead." I now favor this approach too, rather than expanding the points at which we replace the root acl_users.
Change History
comment:2 Changed 6 years ago by davisagli
I hate trac.
aclark: What about eliminating need for top PAS? davisagli: maybe. without root-level PAS you can't log in via Plone UI with a Zope-level account. mcdonc: this convert the root user folder due to voodoo is one of my bugaboos.. instead of piling more hacks on, maybe just dont do it? davisagli: true, it's unneeded unless you're sharing Manager users between multiple sites. could probably be optional. aclark: Well we should at least be able to answer the question "why is this necessary?" If it smells like a hack-a-round… MJ: How about we fix PAS in Plone then? Add a Zope userfolder source instead of hacking the top-level userfolder? davisagli: sounds like a good idea to me
comment:3 Changed 6 years ago by mj
I always thought that Plone replacing the top-level acl_users folder was a bad idea. It should be easy enough to fix the PAS folder in Plone itself to support a non-PAS top-level acl_users as a users source instead. That would fix the bad practice of changing stuff outside the Plone Site object and fix your bug too.
comment:4 Changed 6 years ago by hannosch
- Milestone changed from 4.0 to 4.x
At this point this isn't a simple bug fix anymore, but needs some halfway involved changes to PlonePAS.
comment:5 Changed 6 years ago by davisagli
- Description modified (diff)
- Summary changed from adding a ZODB mountpoint doesn't convert root acl_users to PAS to Plone should not force switching the Zope root acl_users to a Pluggable Auth System.
comment:6 Changed 6 years ago by raphael
https://dev.plone.org/plone/ticket/9929 suggest a different fix for this. It is not a duplicate but I think it would resolve this issue as well.
comment:8 Changed 6 years ago by kleist
We should really document "The current recommendation for dealing with this is to simply add and then delete a dummy Plone site to trigger the acl_users conversion.".
It's an FAQ on #plone.
comment:10 Changed 5 years ago by kleist
Don't know if it's relevant, but #9929 has been fixed as with plone.app.portlets 2.1.2. see: http://dev.plone.org/plone/changeset/47327/plone.app.portlets/trunk
comment:11 Changed 5 years ago by rossp
- Status changed from new to closed
- Resolution set to wontfix
PLEASE READ THIS AND RE-OPEN VALID PLIPS!
As we launch the new PLIP process we'd like to see which PLIPs:
- are still appropriate/needed
- still have owners/proposers/champions
- still have available implementers
If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.
comment:13 Changed 4 years ago by keul
- Status changed from closed to confirmed
- Version set to 4.1
I want to add a commnent related to this issue, even if this is closed.
Right now the upgrade procedure can perform a very long and useless task.
We have a Plone environment full of external database loaded with mountpoints, with big sites inside. If we add there an additional Plone site, this time in the main Data.fs, the "*descend*" method from "PluggableAuthService" is called.
This try to upgrade every permission map from every content type in every site, but this task is useless: those site already have a well-formed map.
We found that commenting the "descend" call fixed the problem.
comment:14 Changed 4 years ago by keul
- Status changed from confirmed to closed
Sorry, I reopened by mistake
Discussion from twitter:
aclark: What about eliminating need for top PAS? davisagli: maybe. without root-level PAS you can't log in via Plone UI with a Zope-level account. mcdonc: this convert the root user folder due to voodoo is one of my bugaboos.. instead of piling more hacks on, maybe just dont do it? davisagli: true, it's unneeded unless you're sharing Manager users between multiple sites. could probably be optional. aclark: Well we should at least be able to answer the question "why is this necessary?" If it smells like a hack-a-round… MJ: How about we fix PAS in Plone then? Add a Zope userfolder source instead of hacking the top-level userfolder? davisagli: sounds like a good idea to me