[xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0
Hi devs, We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg: xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService (Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.) So this vote is about changing the default in xwiki.cfg before 5.0M2. pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1 WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi Denis, Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression. Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ? Jérôme
- may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On 03/14/2013 06:12 PM, Jerome Velociter wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
I'm not entirely sure what "no admin right by default" means. If default documents are not installed with PR then it's a great improvement but also a major break (we should have a vote for that specific rule change). If I cannot get PR to run groovy scripts on the wiki w/o enabling superadmin then -1. I think we can get a better idea of what this means by throwing together another rights service which tries both the new service and the old one and logs a warning if they disagree, running the functional tests with this information would tell us a lot more about how this behaves in practice. We can also collect hard performance data. Thanks, Caleb
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
Jérôme
- may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle < [email protected]> wrote:
On 03/14/2013 06:12 PM, Jerome Velociter wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this
for a
later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
I'm not entirely sure what "no admin right by default" means. If default documents are not installed with PR then it's a great improvement but also a major break (we should have a vote for that specific rule change). If I cannot get PR to run groovy scripts on the wiki w/o enabling superadmin then -1.
No, you get it wrong. It simply means, that if the admin right is not explicitly allowed, it is denied by default. The most important consequence is for an empty DB, since you do not receive admin rights when your are a "null" user. (Even more, a "null" user never receive rights) This is not so serious since now we have the DW that reach PR right in its own way, and is able to deploy a wiki. Only power user that are skipping the DW and wanting to import a XAR will need to login as superadmin to do so.
I think we can get a better idea of what this means by throwing together another rights service which tries both the new service and the old one and logs a warning if they disagree, running the functional tests with this information would tell us a lot more about how this behaves in practice. We can also collect hard performance data.
Setting up this dual RightService is easy, making it pass over all possible situation if really harder. Please note that, while I propose to change the default, this does not prevent a user to configure back the old RightService. Note also, that both services could be used side-by-side, so that new component using the new right service, may work in that configuration. IMO, if we never decide to go forward, we have no chance to discover and improve the new service. It was there during the whole 4.x cycle, and very few committers look at it. A new major version release is therefore the ideal time to go on. We can justify some breakage, and we may fix them during the 5.x cycle.
Thanks, Caleb
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki)
user in a local group has no effect ?
Jérôme
- may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data
structure,
cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On 03/14/2013 06:49 PM, Denis Gervalle wrote:
On Thu, Mar 14, 2013 at 11:28 PM, Caleb James DeLisle < [email protected]> wrote:
On 03/14/2013 06:12 PM, Jerome Velociter wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this
for a
later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
I'm not entirely sure what "no admin right by default" means. If default documents are not installed with PR then it's a great improvement but also a major break (we should have a vote for that specific rule change). If I cannot get PR to run groovy scripts on the wiki w/o enabling superadmin then -1.
No, you get it wrong. It simply means, that if the admin right is not explicitly allowed, it is denied by default. The most important consequence is for an empty DB, since you do not receive admin rights when your are a "null" user. (Even more, a "null" user never receive rights)
This is not so serious since now we have the DW that reach PR right in its own way, and is able to deploy a wiki. Only power user that are skipping the DW and wanting to import a XAR will need to login as superadmin to do so.
I think we can get a better idea of what this means by throwing together another rights service which tries both the new service and the old one and logs a warning if they disagree, running the functional tests with this information would tell us a lot more about how this behaves in practice. We can also collect hard performance data.
Setting up this dual RightService is easy, making it pass over all possible situation if really harder.
Please note that, while I propose to change the default, this does not prevent a user to configure back the old RightService. Note also, that both services could be used side-by-side, so that new component using the new right service, may work in that configuration.
IMO, if we never decide to go forward, we have no chance to discover and improve the new service. It was there during the whole 4.x cycle, and very few committers look at it. A new major version release is therefore the ideal time to go on. We can justify some breakage, and we may fix them during the 5.x cycle.
Indeed we can't pass over every possibility but if we can run the functional tests and have a good explanation for each discrepancy then the change is pretty safe. Users who tread off the common path are used to bugs because all software has little testing of uncommon codepaths. Tentative +1 but I still really want to see some numbers :) Thanks, Caleb
Thanks, Caleb
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki)
user in a local group has no effect ?
Jérôme
- may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data
structure,
cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]>wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** internal.**XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.**authorization.**AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491
- no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki. I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]
wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default
right
service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
internal.**XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.**authorization.**AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491
- no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users. This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible I think even Workspaces is using that so XEM by default would fail with this. Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the
old
one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]
wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while
now,
and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
internal.**XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.**authorization.**AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491
- no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here. IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users. That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching. I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm. This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably
better
than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]
wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while
now,
and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
internal.**XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.**authorization.**AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491
- no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right? Thanks -Vincent
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably
better
than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected]
wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs, > > We have a new (component based) authorization module since a while
now,
> and I think 5.0 is the perfect time to introduce it as the default right > service. First, I simply propose to change the default in xwiki.cfg: > > >
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
> internal.**XWikiCachingRightService > > (Later, I propose that we deprecate that bridge and that we create a > friendly (xwiki oriented) interface over the more generic > org.xwiki.security.**authorization.**AuthorizationManager. But leave > this for a > later proposal.) > > So this vote is about changing the default in xwiki.cfg before 5.0M2. > > pros: > - improved performance, since the new service is using caching > techniques > and a single page load required lots of calls to it. > - ability for extension to add new rights > - define right declaratively > - separate method for checking and verifying right (throws opposed to > boolean return) > - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as > some unstated ones > > Also XWIKI-4550
- possibility to easily solve issues like XWIKI-4491 > - no more admin right per default > - being in good position to improve it and release dependencies to > oldcore for security matters. > - possibility for third party to adapt the right settler to their > special > needs (right decision is plugable) > - a consistant right evaluation with very few exception that could be > explained and documented > > cons: > - no more admin right per default, but since we have DW, the initial > setup is no more a problem, and advanced users may use superadmin. > - groups are only checked from the user wiki, not from the accessed > entity wiki. >
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so. WDYT ?
Thanks -Vincent
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
> implementation (but mostly consistency fixes) > - test could be improved, critical part (right, settler, data > structure, > cache) are covered at almost 100%, api at 60%, this is probably
better
> than the old right service > - documentation should be improved, but this is not worse than the old > one anyway > > Since I use the new module in all my production servers for several > months > with success, and I really think that if we do not do it now we will > never > go ahead, here is my big +1 > > WDYT ?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected]
wrote:
Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote: > > Hi devs, >> >> We have a new (component based) authorization module since a while now, >> and I think 5.0 is the perfect time to introduce it as the default right >> service. First, I simply propose to change the default in xwiki.cfg: >> >> >>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>> internal.**XWikiCachingRightService >> >> (Later, I propose that we deprecate that bridge and that we create a >> friendly (xwiki oriented) interface over the more generic >> org.xwiki.security.**authorization.**AuthorizationManager. But leave >> this for a >> later proposal.) >> >> So this vote is about changing the default in xwiki.cfg before 5.0M2. >> >> pros: >> - improved performance, since the new service is using caching >> techniques >> and a single page load required lots of calls to it. >> - ability for extension to add new rights >> - define right declaratively >> - separate method for checking and verifying right (throws opposed to >> boolean return) >> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as >> some unstated ones >> >> Also XWIKI-4550 > > - possibility to easily solve issues like XWIKI-4491 >> - no more admin right per default >> - being in good position to improve it and release dependencies to >> oldcore for security matters. >> - possibility for third party to adapt the right settler to their >> special >> needs (right decision is plugable) >> - a consistant right evaluation with very few exception that could be >> explained and documented >> >> cons: >> - no more admin right per default, but since we have DW, the initial >> setup is no more a problem, and advanced users may use superadmin. >> - groups are only checked from the user wiki, not from the accessed >> entity wiki. >> > This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost… Thanks -Vincent
WDYT ?
Thanks -Vincent
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing >> implementation (but mostly consistency fixes) >> - test could be improved, critical part (right, settler, data >> structure, >> cache) are covered at almost 100%, api at 60%, this is probably
better
>> than the old right service >> - documentation should be improved, but this is not worse than the old >> one anyway >> >> Since I use the new module in all my production servers for several >> months >> with success, and I really think that if we do not do it now we will >> never >> go ahead, here is my big +1 >> >> WDYT ?
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected] > wrote:
> Hi Denis, > > Le 14/03/13 22:59, Denis Gervalle a écrit : > > On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote: >> >> Hi devs, >>> >>> We have a new (component based) authorization module since a while now, >>> and I think 5.0 is the perfect time to introduce it as the default right >>> service. First, I simply propose to change the default in
xwiki.cfg:
>>> >>> >>>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>> internal.**XWikiCachingRightService >>> >>> (Later, I propose that we deprecate that bridge and that we create a >>> friendly (xwiki oriented) interface over the more generic >>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>> this for a >>> later proposal.) >>> >>> So this vote is about changing the default in xwiki.cfg before 5.0M2. >>> >>> pros: >>> - improved performance, since the new service is using caching >>> techniques >>> and a single page load required lots of calls to it. >>> - ability for extension to add new rights >>> - define right declaratively >>> - separate method for checking and verifying right (throws opposed to >>> boolean return) >>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as >>> some unstated ones >>> >>> Also XWIKI-4550 >> >> - possibility to easily solve issues like XWIKI-4491 >>> - no more admin right per default >>> - being in good position to improve it and release dependencies to >>> oldcore for security matters. >>> - possibility for third party to adapt the right settler to their >>> special >>> needs (right decision is plugable) >>> - a consistant right evaluation with very few exception that could be >>> explained and documented >>> >>> cons: >>> - no more admin right per default, but since we have DW, the initial >>> setup is no more a problem, and advanced users may use superadmin. >>> - groups are only checked from the user wiki, not from the accessed >>> entity wiki. >>> >> > This sound like a big regression. > > Can you explicit more ? Does this mean that adding a global (main wiki) > user in a local group has no effect ? >
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case. I am just saying that while I would like the new module as a default, this does not prevent a user to use the old one until we properly support that particular feature.
Thanks -Vincent
WDYT ?
Thanks -Vincent
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost
impossible
I think even Workspaces is using that so XEM by default would fail
with
this.
Ludovic
> > Jérôme > > > - may exhibit some other minor differences compare to existing >>> implementation (but mostly consistency fixes) >>> - test could be improved, critical part (right, settler, data >>> structure, >>> cache) are covered at almost 100%, api at 60%, this is probably
better
>>> than the old right service >>> - documentation should be improved, but this is not worse than the old >>> one anyway >>> >>> Since I use the new module in all my production servers for several >>> months >>> with success, and I really think that if we do not do it now we will >>> never >>> go ahead, here is my big +1 >>> >>> WDYT ?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected] >> wrote: > >> Hi Denis, >> >> Le 14/03/13 22:59, Denis Gervalle a écrit : >> >> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote: >>> >>> Hi devs, >>>> >>>> We have a new (component based) authorization module since a while now, >>>> and I think 5.0 is the perfect time to introduce it as the default > right >>>> service. First, I simply propose to change the default in
xwiki.cfg:
>>>> >>>> >>>> > xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>> internal.**XWikiCachingRightService >>>> >>>> (Later, I propose that we deprecate that bridge and that we create a >>>> friendly (xwiki oriented) interface over the more generic >>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>> this for a >>>> later proposal.) >>>> >>>> So this vote is about changing the default in xwiki.cfg before 5.0M2. >>>> >>>> pros: >>>> - improved performance, since the new service is using caching >>>> techniques >>>> and a single page load required lots of calls to it. >>>> - ability for extension to add new rights >>>> - define right declaratively >>>> - separate method for checking and verifying right (throws opposed to >>>> boolean return) >>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as >>>> some unstated ones >>>> >>>> Also XWIKI-4550 >>> >>> - possibility to easily solve issues like XWIKI-4491 >>>> - no more admin right per default >>>> - being in good position to improve it and release dependencies to >>>> oldcore for security matters. >>>> - possibility for third party to adapt the right settler to their >>>> special >>>> needs (right decision is plugable) >>>> - a consistant right evaluation with very few exception that could be >>>> explained and documented >>>> >>>> cons: >>>> - no more admin right per default, but since we have DW, the initial >>>> setup is no more a problem, and advanced users may use superadmin. >>>> - groups are only checked from the user wiki, not from the accessed >>>> entity wiki. >>>> >>> >> This sound like a big regression. >> >> Can you explicit more ? Does this mean that adding a global (main wiki) >> user in a local group has no effect ? >> > > You have got it right. This could be improved, and help is welcome. What > happen is that the user groups are evaluated independently to the targeted > entity, and therefore only in the user wiki. > > I admit this is a regression, but I have not cross lots of use case like > those. The simple display in admin of Global user in local Group is even > broken (double xwiki:xwiki:...) so this does not seems to me a common > usage. > You may provide access to global group in a local wiki to achieve the same > goals. > > This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ? JV.
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
> 2013/3/14 Denis Gervalle <[email protected]> > >> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected] >>> wrote: >> >>> Hi Denis, >>> >>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>> >>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> > wrote: >>>> >>>> Hi devs, >>>>> >>>>> We have a new (component based) authorization module since a
while
> now, >>>>> and I think 5.0 is the perfect time to introduce it as the default >> right >>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>> >>>>> >>>>> >>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>>>> internal.**XWikiCachingRightService >>>>> >>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>> friendly (xwiki oriented) interface over the more generic >>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>> this for a >>>>> later proposal.) >>>>> >>>>> So this vote is about changing the default in xwiki.cfg before 5.0M2. >>>>> >>>>> pros: >>>>> - improved performance, since the new service is using caching >>>>> techniques >>>>> and a single page load required lots of calls to it. >>>>> - ability for extension to add new rights >>>>> - define right declaratively >>>>> - separate method for checking and verifying right (throws opposed > to >>>>> boolean return) >>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well > as >>>>> some unstated ones >>>>> >>>>> Also XWIKI-4550 >>>> >>>> - possibility to easily solve issues like XWIKI-4491 >>>>> - no more admin right per default >>>>> - being in good position to improve it and release dependencies to >>>>> oldcore for security matters. >>>>> - possibility for third party to adapt the right settler to their >>>>> special >>>>> needs (right decision is plugable) >>>>> - a consistant right evaluation with very few exception that could > be >>>>> explained and documented >>>>> >>>>> cons: >>>>> - no more admin right per default, but since we have DW, the > initial >>>>> setup is no more a problem, and advanced users may use superadmin. >>>>> - groups are only checked from the user wiki, not from the accessed >>>>> entity wiki. >>>>> >>>> >>> This sound like a big regression. >>> >>> Can you explicit more ? Does this mean that adding a global (main wiki) >>> user in a local group has no effect ? >>> >> >> You have got it right. This could be improved, and help is welcome. What >> happen is that the user groups are evaluated independently to the > targeted >> entity, and therefore only in the user wiki. >> >> I admit this is a regression, but I have not cross lots of use case like >> those. The simple display in admin of Global user in local Group is even >> broken (double xwiki:xwiki:...) so this does not seems to me a common >> usage. >> You may provide access to global group in a local wiki to achieve the > same >> goals. >> >> > This looks to be indeed a big regression. It's quite a common use case to > have only global users and to create groups in the local wiki that refer to > local users. > ^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know > plenty of projects for which migration to 5.0 would be almost impossible >
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO. See my reply to Ludovic for more about how we need to work on that missing feature.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote: > >> 2013/3/14 Denis Gervalle <[email protected]> >> >>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected] >>>> wrote: >>> >>>> Hi Denis, >>>> >>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>> >>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >> wrote: >>>>> >>>>> Hi devs, >>>>>> >>>>>> We have a new (component based) authorization module since a
while
>> now, >>>>>> and I think 5.0 is the perfect time to introduce it as the default >>> right >>>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>>> >>>>>> >>>>>> >>>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>>>>> internal.**XWikiCachingRightService >>>>>> >>>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>>> friendly (xwiki oriented) interface over the more generic >>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>>> this for a >>>>>> later proposal.) >>>>>> >>>>>> So this vote is about changing the default in xwiki.cfg before 5.0M2. >>>>>> >>>>>> pros: >>>>>> - improved performance, since the new service is using caching >>>>>> techniques >>>>>> and a single page load required lots of calls to it. >>>>>> - ability for extension to add new rights >>>>>> - define right declaratively >>>>>> - separate method for checking and verifying right (throws opposed >> to >>>>>> boolean return) >>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >> as >>>>>> some unstated ones >>>>>> >>>>>> Also XWIKI-4550 >>>>> >>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>> - no more admin right per default >>>>>> - being in good position to improve it and release dependencies to >>>>>> oldcore for security matters. >>>>>> - possibility for third party to adapt the right settler to their >>>>>> special >>>>>> needs (right decision is plugable) >>>>>> - a consistant right evaluation with very few exception that could >> be >>>>>> explained and documented >>>>>> >>>>>> cons: >>>>>> - no more admin right per default, but since we have DW, the >> initial >>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>> - groups are only checked from the user wiki, not from the accessed >>>>>> entity wiki. >>>>>> >>>>> >>>> This sound like a big regression. >>>> >>>> Can you explicit more ? Does this mean that adding a global (main wiki) >>>> user in a local group has no effect ? >>>> >>> >>> You have got it right. This could be improved, and help is welcome. What >>> happen is that the user groups are evaluated independently to the >> targeted >>> entity, and therefore only in the user wiki. >>> >>> I admit this is a regression, but I have not cross lots of use case like >>> those. The simple display in admin of Global user in local Group is even >>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>> usage. >>> You may provide access to global group in a local wiki to achieve the >> same >>> goals. >>> >>> >> This looks to be indeed a big regression. It's quite a common use case to >> have only global users and to create groups in the local wiki that refer to >> local users. >> > ^^^^^^^^ > I suppose you means global users here. > > IMHO, having user managed by a separate entity (global admin), and these > same individual users grouped by another one (local admin) is very uncommon > delegation of authority to me (but I may be wrong). On the other hand, > having a local admin providing access to local ressources to global group > (and potentially some global users) makes more sense. In that way, the same > admin manage its users, and group its users, and the local admin trust the > global admin to know its users. > > That said, I am not against any improvement on the way it works, if it is a > common use case (moreover used by workspace), we should obviously support > it. However, I am convince that evaluating groups based on both the user > and the targeted entity is not easily achievable and conduct to very > complex partial caching. > > I have currently not implemented in the security module anything that would > cause all wikis to be scanned, and I would really like to avoid that to > happen. So, it will be difficult to avoid partial caching, but we need to > limit that at the higher level, the subwiki. This would allow to had only > scan both the wiki of the user and the target entry to consider our cache > valid. It means subwiki will be unable to share groups (I do not think this > has ever worked), but it will keep performance on large farm. > > This would really need to be fixed sooner than later otherwise I know >> plenty of projects for which migration to 5.0 would be almost impossible >> > > I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice. I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this. In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests? Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]
wrote:
> > On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: > >> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]
> wrote: >> >>> 2013/3/14 Denis Gervalle <[email protected]> >>> >>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < > [email protected] >>>>> wrote: >>>> >>>>> Hi Denis, >>>>> >>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>> >>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >>> wrote: >>>>>> >>>>>> Hi devs, >>>>>>> >>>>>>> We have a new (component based) authorization module since a while >>> now, >>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>> right >>>>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>>>> >>>>>>> >>>>>>> >>>> > xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>>>>> internal.**XWikiCachingRightService >>>>>>> >>>>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>>>> this for a >>>>>>> later proposal.) >>>>>>> >>>>>>> So this vote is about changing the default in xwiki.cfg before > 5.0M2. >>>>>>> >>>>>>> pros: >>>>>>> - improved performance, since the new service is using caching >>>>>>> techniques >>>>>>> and a single page load required lots of calls to it. >>>>>>> - ability for extension to add new rights >>>>>>> - define right declaratively >>>>>>> - separate method for checking and verifying right (throws opposed >>> to >>>>>>> boolean return) >>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>> as >>>>>>> some unstated ones >>>>>>> >>>>>>> Also XWIKI-4550 >>>>>> >>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>> - no more admin right per default >>>>>>> - being in good position to improve it and release dependencies to >>>>>>> oldcore for security matters. >>>>>>> - possibility for third party to adapt the right settler to their >>>>>>> special >>>>>>> needs (right decision is plugable) >>>>>>> - a consistant right evaluation with very few exception that could >>> be >>>>>>> explained and documented >>>>>>> >>>>>>> cons: >>>>>>> - no more admin right per default, but since we have DW, the >>> initial >>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>> - groups are only checked from the user wiki, not from the accessed >>>>>>> entity wiki. >>>>>>> >>>>>> >>>>> This sound like a big regression. >>>>> >>>>> Can you explicit more ? Does this mean that adding a global (main > wiki) >>>>> user in a local group has no effect ? >>>>> >>>> >>>> You have got it right. This could be improved, and help is welcome. > What >>>> happen is that the user groups are evaluated independently to the >>> targeted >>>> entity, and therefore only in the user wiki. >>>> >>>> I admit this is a regression, but I have not cross lots of use case > like >>>> those. The simple display in admin of Global user in local Group is > even >>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>> usage. >>>> You may provide access to global group in a local wiki to achieve the >>> same >>>> goals. >>>> >>>> >>> This looks to be indeed a big regression. It's quite a common use case > to >>> have only global users and to create groups in the local wiki that > refer to >>> local users. >>> >> ^^^^^^^^ >> I suppose you means global users here. >> >> IMHO, having user managed by a separate entity (global admin), and these >> same individual users grouped by another one (local admin) is very > uncommon >> delegation of authority to me (but I may be wrong). On the other hand, >> having a local admin providing access to local ressources to global group >> (and potentially some global users) makes more sense. In that way, the > same >> admin manage its users, and group its users, and the local admin trust > the >> global admin to know its users. >> >> That said, I am not against any improvement on the way it works, if it > is a >> common use case (moreover used by workspace), we should obviously support >> it. However, I am convince that evaluating groups based on both the user >> and the targeted entity is not easily achievable and conduct to very >> complex partial caching. >> >> I have currently not implemented in the security module anything that > would >> cause all wikis to be scanned, and I would really like to avoid that to >> happen. So, it will be difficult to avoid partial caching, but we need to >> limit that at the higher level, the subwiki. This would allow to had only >> scan both the wiki of the user and the target entry to consider our cache >> valid. It means subwiki will be unable to share groups (I do not think > this >> has ever worked), but it will keep performance on large farm. >> >> This would really need to be fixed sooner than later otherwise I know >>> plenty of projects for which migration to 5.0 would be almost impossible >>> >> >> I will need helps to achieve that for 5.0 > > ok so before changing anything we need a plan i.e. someone volunteering to > work on this, right? >
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside. I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta) UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests. Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC. So, do you agree to go that way and give this long awaited improvement a real boost ?
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Mar 15, 2013, at 8:44 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]
wrote: > >> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: >> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]
>> wrote: >>> >>>> 2013/3/14 Denis Gervalle <[email protected]> >>>> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >> [email protected] >>>>>> wrote: >>>>> >>>>>> Hi Denis, >>>>>> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >>>> wrote: >>>>>>> >>>>>>> Hi devs, >>>>>>>> >>>>>>>> We have a new (component based) authorization module since a while >>>> now, >>>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>>> right >>>>>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >> xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>>>>>> internal.**XWikiCachingRightService >>>>>>>> >>>>>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>>>>> this for a >>>>>>>> later proposal.) >>>>>>>> >>>>>>>> So this vote is about changing the default in xwiki.cfg before >> 5.0M2. >>>>>>>> >>>>>>>> pros: >>>>>>>> - improved performance, since the new service is using caching >>>>>>>> techniques >>>>>>>> and a single page load required lots of calls to it. >>>>>>>> - ability for extension to add new rights >>>>>>>> - define right declaratively >>>>>>>> - separate method for checking and verifying right (throws opposed >>>> to >>>>>>>> boolean return) >>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>>> as >>>>>>>> some unstated ones >>>>>>>> >>>>>>>> Also XWIKI-4550 >>>>>>> >>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>> - no more admin right per default >>>>>>>> - being in good position to improve it and release dependencies to >>>>>>>> oldcore for security matters. >>>>>>>> - possibility for third party to adapt the right settler to their >>>>>>>> special >>>>>>>> needs (right decision is plugable) >>>>>>>> - a consistant right evaluation with very few exception that could >>>> be >>>>>>>> explained and documented >>>>>>>> >>>>>>>> cons: >>>>>>>> - no more admin right per default, but since we have DW, the >>>> initial >>>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>>> - groups are only checked from the user wiki, not from the accessed >>>>>>>> entity wiki. >>>>>>>> >>>>>>> >>>>>> This sound like a big regression. >>>>>> >>>>>> Can you explicit more ? Does this mean that adding a global (main >> wiki) >>>>>> user in a local group has no effect ? >>>>>> >>>>> >>>>> You have got it right. This could be improved, and help is welcome. >> What >>>>> happen is that the user groups are evaluated independently to the >>>> targeted >>>>> entity, and therefore only in the user wiki. >>>>> >>>>> I admit this is a regression, but I have not cross lots of use case >> like >>>>> those. The simple display in admin of Global user in local Group is >> even >>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>>> usage. >>>>> You may provide access to global group in a local wiki to achieve the >>>> same >>>>> goals. >>>>> >>>>> >>>> This looks to be indeed a big regression. It's quite a common use case >> to >>>> have only global users and to create groups in the local wiki that >> refer to >>>> local users. >>>> >>> ^^^^^^^^ >>> I suppose you means global users here. >>> >>> IMHO, having user managed by a separate entity (global admin), and these >>> same individual users grouped by another one (local admin) is very >> uncommon >>> delegation of authority to me (but I may be wrong). On the other hand, >>> having a local admin providing access to local ressources to global group >>> (and potentially some global users) makes more sense. In that way, the >> same >>> admin manage its users, and group its users, and the local admin trust >> the >>> global admin to know its users. >>> >>> That said, I am not against any improvement on the way it works, if it >> is a >>> common use case (moreover used by workspace), we should obviously support >>> it. However, I am convince that evaluating groups based on both the user >>> and the targeted entity is not easily achievable and conduct to very >>> complex partial caching. >>> >>> I have currently not implemented in the security module anything that >> would >>> cause all wikis to be scanned, and I would really like to avoid that to >>> happen. So, it will be difficult to avoid partial caching, but we need to >>> limit that at the higher level, the subwiki. This would allow to had only >>> scan both the wiki of the user and the target entry to consider our cache >>> valid. It means subwiki will be unable to share groups (I do not think >> this >>> has ever worked), but it will keep performance on large farm. >>> >>> This would really need to be fixed sooner than later otherwise I know >>>> plenty of projects for which migration to 5.0 would be almost impossible >>>> >>> >>> I will need helps to achieve that for 5.0 >> >> ok so before changing anything we need a plan i.e. someone volunteering to >> work on this, right? >> > > Do we really need that for 5.0 ? > Using the new module as a default does not means the old right service is > unavailable. Couldn't we simply define which case needs to revert to the > old modules in the RN, and have 5.0 without this feature ? We may even > release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta)
UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests.
Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a real boost ?
Sure, and all the more since I'm on holidays so I'll let you guys fix the build instability :) I just hope it'll be nice and stable again when I'm back in one week! :) Have fun Thanks -Vincent
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
On Fri, Mar 15, 2013 at 8:44 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]
wrote: > >> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: >> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]
>> wrote: >>> >>>> 2013/3/14 Denis Gervalle <[email protected]> >>>> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >> [email protected] >>>>>> wrote: >>>>> >>>>>> Hi Denis, >>>>>> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >>>> wrote: >>>>>>> >>>>>>> Hi devs, >>>>>>>> >>>>>>>> We have a new (component based) authorization module since a while >>>> now, >>>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>>> right >>>>>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >> xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>>>>>> internal.**XWikiCachingRightService >>>>>>>> >>>>>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>>>>> this for a >>>>>>>> later proposal.) >>>>>>>> >>>>>>>> So this vote is about changing the default in xwiki.cfg before >> 5.0M2. >>>>>>>> >>>>>>>> pros: >>>>>>>> - improved performance, since the new service is using caching >>>>>>>> techniques >>>>>>>> and a single page load required lots of calls to it. >>>>>>>> - ability for extension to add new rights >>>>>>>> - define right declaratively >>>>>>>> - separate method for checking and verifying right (throws opposed >>>> to >>>>>>>> boolean return) >>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>>> as >>>>>>>> some unstated ones >>>>>>>> >>>>>>>> Also XWIKI-4550 >>>>>>> >>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>> - no more admin right per default >>>>>>>> - being in good position to improve it and release dependencies to >>>>>>>> oldcore for security matters. >>>>>>>> - possibility for third party to adapt the right settler to their >>>>>>>> special >>>>>>>> needs (right decision is plugable) >>>>>>>> - a consistant right evaluation with very few exception that could >>>> be >>>>>>>> explained and documented >>>>>>>> >>>>>>>> cons: >>>>>>>> - no more admin right per default, but since we have DW, the >>>> initial >>>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>>> - groups are only checked from the user wiki, not from the accessed >>>>>>>> entity wiki. >>>>>>>> >>>>>>> >>>>>> This sound like a big regression. >>>>>> >>>>>> Can you explicit more ? Does this mean that adding a global (main >> wiki) >>>>>> user in a local group has no effect ? >>>>>> >>>>> >>>>> You have got it right. This could be improved, and help is welcome. >> What >>>>> happen is that the user groups are evaluated independently to the >>>> targeted >>>>> entity, and therefore only in the user wiki. >>>>> >>>>> I admit this is a regression, but I have not cross lots of use case >> like >>>>> those. The simple display in admin of Global user in local Group is >> even >>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>>> usage. >>>>> You may provide access to global group in a local wiki to achieve the >>>> same >>>>> goals. >>>>> >>>>> >>>> This looks to be indeed a big regression. It's quite a common use case >> to >>>> have only global users and to create groups in the local wiki that >> refer to >>>> local users. >>>> >>> ^^^^^^^^ >>> I suppose you means global users here. >>> >>> IMHO, having user managed by a separate entity (global admin), and these >>> same individual users grouped by another one (local admin) is very >> uncommon >>> delegation of authority to me (but I may be wrong). On the other hand, >>> having a local admin providing access to local ressources to global group >>> (and potentially some global users) makes more sense. In that way, the >> same >>> admin manage its users, and group its users, and the local admin trust >> the >>> global admin to know its users. >>> >>> That said, I am not against any improvement on the way it works, if it >> is a >>> common use case (moreover used by workspace), we should obviously support >>> it. However, I am convince that evaluating groups based on both the user >>> and the targeted entity is not easily achievable and conduct to very >>> complex partial caching. >>> >>> I have currently not implemented in the security module anything that >> would >>> cause all wikis to be scanned, and I would really like to avoid that to >>> happen. So, it will be difficult to avoid partial caching, but we need to >>> limit that at the higher level, the subwiki. This would allow to had only >>> scan both the wiki of the user and the target entry to consider our cache >>> valid. It means subwiki will be unable to share groups (I do not think >> this >>> has ever worked), but it will keep performance on large farm. >>> >>> This would really need to be fixed sooner than later otherwise I know >>>> plenty of projects for which migration to 5.0 would be almost impossible >>>> >>> >>> I will need helps to achieve that for 5.0 >> >> ok so before changing anything we need a plan i.e. someone volunteering to >> work on this, right? >> > > Do we really need that for 5.0 ? > Using the new module as a default does not means the old right service is > unavailable. Couldn't we simply define which case needs to revert to the > old modules in the RN, and have 5.0 without this feature ? We may even > release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta)
UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests.
Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a real boost ?
+1
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]
wrote: > >> >> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: >> >>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]
>> wrote: >>> >>>> 2013/3/14 Denis Gervalle <[email protected]> >>>> >>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >> [email protected] >>>>>> wrote: >>>>> >>>>>> Hi Denis, >>>>>> >>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>> >>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> >>>> wrote: >>>>>>> >>>>>>> Hi devs, >>>>>>>> >>>>>>>> We have a new (component based) authorization module since a while >>>> now, >>>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>>> right >>>>>>>> service. First, I simply propose to change the default in xwiki.cfg: >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >> xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.** >>>>>>>> internal.**XWikiCachingRightService >>>>>>>> >>>>>>>> (Later, I propose that we deprecate that bridge and that we create a >>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>>>>>> this for a >>>>>>>> later proposal.) >>>>>>>> >>>>>>>> So this vote is about changing the default in xwiki.cfg before >> 5.0M2. >>>>>>>> >>>>>>>> pros: >>>>>>>> - improved performance, since the new service is using caching >>>>>>>> techniques >>>>>>>> and a single page load required lots of calls to it. >>>>>>>> - ability for extension to add new rights >>>>>>>> - define right declaratively >>>>>>>> - separate method for checking and verifying right (throws opposed >>>> to >>>>>>>> boolean return) >>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>>> as >>>>>>>> some unstated ones >>>>>>>> >>>>>>>> Also XWIKI-4550 >>>>>>> >>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>> - no more admin right per default >>>>>>>> - being in good position to improve it and release dependencies to >>>>>>>> oldcore for security matters. >>>>>>>> - possibility for third party to adapt the right settler to their >>>>>>>> special >>>>>>>> needs (right decision is plugable) >>>>>>>> - a consistant right evaluation with very few exception that could >>>> be >>>>>>>> explained and documented >>>>>>>> >>>>>>>> cons: >>>>>>>> - no more admin right per default, but since we have DW, the >>>> initial >>>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>>> - groups are only checked from the user wiki, not from the accessed >>>>>>>> entity wiki. >>>>>>>> >>>>>>> >>>>>> This sound like a big regression. >>>>>> >>>>>> Can you explicit more ? Does this mean that adding a global (main >> wiki) >>>>>> user in a local group has no effect ? >>>>>> >>>>> >>>>> You have got it right. This could be improved, and help is welcome. >> What >>>>> happen is that the user groups are evaluated independently to the >>>> targeted >>>>> entity, and therefore only in the user wiki. >>>>> >>>>> I admit this is a regression, but I have not cross lots of use case >> like >>>>> those. The simple display in admin of Global user in local Group is >> even >>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>>> usage. >>>>> You may provide access to global group in a local wiki to achieve the >>>> same >>>>> goals. >>>>> >>>>> >>>> This looks to be indeed a big regression. It's quite a common use case >> to >>>> have only global users and to create groups in the local wiki that >> refer to >>>> local users. >>>> >>> ^^^^^^^^ >>> I suppose you means global users here. >>> >>> IMHO, having user managed by a separate entity (global admin), and these >>> same individual users grouped by another one (local admin) is very >> uncommon >>> delegation of authority to me (but I may be wrong). On the other hand, >>> having a local admin providing access to local ressources to global group >>> (and potentially some global users) makes more sense. In that way, the >> same >>> admin manage its users, and group its users, and the local admin trust >> the >>> global admin to know its users. >>> >>> That said, I am not against any improvement on the way it works, if it >> is a >>> common use case (moreover used by workspace), we should obviously support >>> it. However, I am convince that evaluating groups based on both the user >>> and the targeted entity is not easily achievable and conduct to very >>> complex partial caching. >>> >>> I have currently not implemented in the security module anything that >> would >>> cause all wikis to be scanned, and I would really like to avoid that to >>> happen. So, it will be difficult to avoid partial caching, but we need to >>> limit that at the higher level, the subwiki. This would allow to had only >>> scan both the wiki of the user and the target entry to consider our cache >>> valid. It means subwiki will be unable to share groups (I do not think >> this >>> has ever worked), but it will keep performance on large farm. >>> >>> This would really need to be fixed sooner than later otherwise I know >>>> plenty of projects for which migration to 5.0 would be almost impossible >>>> >>> >>> I will need helps to achieve that for 5.0 >> >> ok so before changing anything we need a plan i.e. someone volunteering to >> work on this, right? >> > > Do we really need that for 5.0 ? > Using the new module as a default does not means the old right service is > unavailable. Couldn't we simply define which case needs to revert to the > old modules in the RN, and have 5.0 without this feature ? We may even > release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta)
UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests.
Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a real boost ?
+1. I'll help fixing the failing tests. Thanks, Marius
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vote has passed with four +1 and mostly general agreement. With Thomas, we have fix the missing features, see XWIKI-8931 and XWIKI-8933, and we are improving unit tests. So, I will switch the default RightService later today, the jira issue is XWIKI-8944 Your help will be welcome to fix any integration tests that start failing after that. Thanks, On Sat, Mar 16, 2013 at 2:36 PM, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]>
wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol < [email protected]> wrote:
> > On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote: > >> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol < [email protected]
> wrote: >> >>> >>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: >>> >>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost < [email protected]
>>> wrote: >>>> >>>>> 2013/3/14 Denis Gervalle <[email protected]> >>>>> >>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >>> [email protected] >>>>>>> wrote: >>>>>> >>>>>>> Hi Denis, >>>>>>> >>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>>> >>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle < [email protected]> >>>>> wrote: >>>>>>>> >>>>>>>> Hi devs, >>>>>>>>> >>>>>>>>> We have a new (component based) authorization module since a while >>>>> now, >>>>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>>>> right >>>>>>>>> service. First, I simply propose to change the default in > xwiki.cfg: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>>>>>>>> internal.**XWikiCachingRightService >>>>>>>>> >>>>>>>>> (Later, I propose that we deprecate that bridge and that we > create a >>>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But > leave >>>>>>>>> this for a >>>>>>>>> later proposal.) >>>>>>>>> >>>>>>>>> So this vote is about changing the default in xwiki.cfg before >>> 5.0M2. >>>>>>>>> >>>>>>>>> pros: >>>>>>>>> - improved performance, since the new service is using caching >>>>>>>>> techniques >>>>>>>>> and a single page load required lots of calls to it. >>>>>>>>> - ability for extension to add new rights >>>>>>>>> - define right declaratively >>>>>>>>> - separate method for checking and verifying right (throws opposed >>>>> to >>>>>>>>> boolean return) >>>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>>>> as >>>>>>>>> some unstated ones >>>>>>>>> >>>>>>>>> Also XWIKI-4550 >>>>>>>> >>>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>>> - no more admin right per default >>>>>>>>> - being in good position to improve it and release dependencies to >>>>>>>>> oldcore for security matters. >>>>>>>>> - possibility for third party to adapt the right settler to their >>>>>>>>> special >>>>>>>>> needs (right decision is plugable) >>>>>>>>> - a consistant right evaluation with very few exception that could >>>>> be >>>>>>>>> explained and documented >>>>>>>>> >>>>>>>>> cons: >>>>>>>>> - no more admin right per default, but since we have DW, the >>>>> initial >>>>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>>>> - groups are only checked from the user wiki, not from the > accessed >>>>>>>>> entity wiki. >>>>>>>>> >>>>>>>> >>>>>>> This sound like a big regression. >>>>>>> >>>>>>> Can you explicit more ? Does this mean that adding a global (main >>> wiki) >>>>>>> user in a local group has no effect ? >>>>>>> >>>>>> >>>>>> You have got it right. This could be improved, and help is welcome. >>> What >>>>>> happen is that the user groups are evaluated independently to the >>>>> targeted >>>>>> entity, and therefore only in the user wiki. >>>>>> >>>>>> I admit this is a regression, but I have not cross lots of use case >>> like >>>>>> those. The simple display in admin of Global user in local Group is >>> even >>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>>>> usage. >>>>>> You may provide access to global group in a local wiki to achieve the >>>>> same >>>>>> goals. >>>>>> >>>>>> >>>>> This looks to be indeed a big regression. It's quite a common use case >>> to >>>>> have only global users and to create groups in the local wiki that >>> refer to >>>>> local users. >>>>> >>>> ^^^^^^^^ >>>> I suppose you means global users here. >>>> >>>> IMHO, having user managed by a separate entity (global admin), and > these >>>> same individual users grouped by another one (local admin) is very >>> uncommon >>>> delegation of authority to me (but I may be wrong). On the other hand, >>>> having a local admin providing access to local ressources to global > group >>>> (and potentially some global users) makes more sense. In that way, the >>> same >>>> admin manage its users, and group its users, and the local admin trust >>> the >>>> global admin to know its users. >>>> >>>> That said, I am not against any improvement on the way it works, if it >>> is a >>>> common use case (moreover used by workspace), we should obviously > support >>>> it. However, I am convince that evaluating groups based on both the > user >>>> and the targeted entity is not easily achievable and conduct to very >>>> complex partial caching. >>>> >>>> I have currently not implemented in the security module anything that >>> would >>>> cause all wikis to be scanned, and I would really like to avoid that to >>>> happen. So, it will be difficult to avoid partial caching, but we need > to >>>> limit that at the higher level, the subwiki. This would allow to had > only >>>> scan both the wiki of the user and the target entry to consider our > cache >>>> valid. It means subwiki will be unable to share groups (I do not think >>> this >>>> has ever worked), but it will keep performance on large farm. >>>> >>>> This would really need to be fixed sooner than later otherwise I know >>>>> plenty of projects for which migration to 5.0 would be almost > impossible >>>>> >>>> >>>> I will need helps to achieve that for 5.0 >>> >>> ok so before changing anything we need a plan i.e. someone volunteering > to >>> work on this, right? >>> >> >> Do we really need that for 5.0 ? >> Using the new module as a default does not means the old right service is >> unavailable. Couldn't we simply define which case needs to revert to the >> old modules in the RN, and have 5.0 without this feature ? We may even >> release XEM without it if workspace need so. > > I thought the config change you were proposing was global… I'm lost… >
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta)
UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests.
Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a real boost ?
+1. I'll help fixing the failing tests.
Thanks, Marius
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi devs, The security module is now documented at http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module and the release notes of upcoming release http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50M2 try to take attention of migrating user to major changes of behavior. I hope I have not missed to mention any unexpected changes and that those change meet your agreement. You are encouraged to review these documentations and comments. Thanks, On Wed, Mar 20, 2013 at 1:40 PM, Denis Gervalle <[email protected]> wrote:
Vote has passed with four +1 and mostly general agreement. With Thomas, we have fix the missing features, see XWIKI-8931 and XWIKI-8933, and we are improving unit tests. So, I will switch the default RightService later today, the jira issue is XWIKI-8944 Your help will be welcome to fix any integration tests that start failing after that.
Thanks,
On Sat, Mar 16, 2013 at 2:36 PM, Marius Dumitru Florea < [email protected]> wrote:
On Fri, Mar 15, 2013 at 9:44 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:35 PM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 12:14 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 12:06 PM, Jean-Vincent Drean <[email protected]> wrote:
On Fri, Mar 15, 2013 at 11:25 AM, Denis Gervalle <[email protected]>
wrote:
> On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol < [email protected]> wrote: > >> >> On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote: >> >>> On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol < [email protected]
>> wrote: >>> >>>> >>>> On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote: >>>> >>>>> On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost < [email protected]
>>>> wrote: >>>>> >>>>>> 2013/3/14 Denis Gervalle <[email protected]> >>>>>> >>>>>>> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < >>>> [email protected] >>>>>>>> wrote: >>>>>>> >>>>>>>> Hi Denis, >>>>>>>> >>>>>>>> Le 14/03/13 22:59, Denis Gervalle a écrit : >>>>>>>> >>>>>>>> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle < [email protected]> >>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi devs, >>>>>>>>>> >>>>>>>>>> We have a new (component based) authorization module since a while >>>>>> now, >>>>>>>>>> and I think 5.0 is the perfect time to introduce it as the default >>>>>>> right >>>>>>>>>> service. First, I simply propose to change the default in >> xwiki.cfg: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>>>>>>>>> internal.**XWikiCachingRightService >>>>>>>>>> >>>>>>>>>> (Later, I propose that we deprecate that bridge and that we >> create a >>>>>>>>>> friendly (xwiki oriented) interface over the more generic >>>>>>>>>> org.xwiki.security.**authorization.**AuthorizationManager. But >> leave >>>>>>>>>> this for a >>>>>>>>>> later proposal.) >>>>>>>>>> >>>>>>>>>> So this vote is about changing the default in xwiki.cfg before >>>> 5.0M2. >>>>>>>>>> >>>>>>>>>> pros: >>>>>>>>>> - improved performance, since the new service is using caching >>>>>>>>>> techniques >>>>>>>>>> and a single page load required lots of calls to it. >>>>>>>>>> - ability for extension to add new rights >>>>>>>>>> - define right declaratively >>>>>>>>>> - separate method for checking and verifying right (throws opposed >>>>>> to >>>>>>>>>> boolean return) >>>>>>>>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well >>>>>> as >>>>>>>>>> some unstated ones >>>>>>>>>> >>>>>>>>>> Also XWIKI-4550 >>>>>>>>> >>>>>>>>> - possibility to easily solve issues like XWIKI-4491 >>>>>>>>>> - no more admin right per default >>>>>>>>>> - being in good position to improve it and release dependencies to >>>>>>>>>> oldcore for security matters. >>>>>>>>>> - possibility for third party to adapt the right settler to their >>>>>>>>>> special >>>>>>>>>> needs (right decision is plugable) >>>>>>>>>> - a consistant right evaluation with very few exception that could >>>>>> be >>>>>>>>>> explained and documented >>>>>>>>>> >>>>>>>>>> cons: >>>>>>>>>> - no more admin right per default, but since we have DW, the >>>>>> initial >>>>>>>>>> setup is no more a problem, and advanced users may use superadmin. >>>>>>>>>> - groups are only checked from the user wiki, not from the >> accessed >>>>>>>>>> entity wiki. >>>>>>>>>> >>>>>>>>> >>>>>>>> This sound like a big regression. >>>>>>>> >>>>>>>> Can you explicit more ? Does this mean that adding a global (main >>>> wiki) >>>>>>>> user in a local group has no effect ? >>>>>>>> >>>>>>> >>>>>>> You have got it right. This could be improved, and help is welcome. >>>> What >>>>>>> happen is that the user groups are evaluated independently to the >>>>>> targeted >>>>>>> entity, and therefore only in the user wiki. >>>>>>> >>>>>>> I admit this is a regression, but I have not cross lots of use case >>>> like >>>>>>> those. The simple display in admin of Global user in local Group is >>>> even >>>>>>> broken (double xwiki:xwiki:...) so this does not seems to me a common >>>>>>> usage. >>>>>>> You may provide access to global group in a local wiki to achieve the >>>>>> same >>>>>>> goals. >>>>>>> >>>>>>> >>>>>> This looks to be indeed a big regression. It's quite a common use case >>>> to >>>>>> have only global users and to create groups in the local wiki that >>>> refer to >>>>>> local users. >>>>>> >>>>> ^^^^^^^^ >>>>> I suppose you means global users here. >>>>> >>>>> IMHO, having user managed by a separate entity (global admin), and >> these >>>>> same individual users grouped by another one (local admin) is very >>>> uncommon >>>>> delegation of authority to me (but I may be wrong). On the other hand, >>>>> having a local admin providing access to local ressources to global >> group >>>>> (and potentially some global users) makes more sense. In that way, the >>>> same >>>>> admin manage its users, and group its users, and the local admin trust >>>> the >>>>> global admin to know its users. >>>>> >>>>> That said, I am not against any improvement on the way it works, if it >>>> is a >>>>> common use case (moreover used by workspace), we should obviously >> support >>>>> it. However, I am convince that evaluating groups based on both the >> user >>>>> and the targeted entity is not easily achievable and conduct to very >>>>> complex partial caching. >>>>> >>>>> I have currently not implemented in the security module anything that >>>> would >>>>> cause all wikis to be scanned, and I would really like to avoid that to >>>>> happen. So, it will be difficult to avoid partial caching, but we need >> to >>>>> limit that at the higher level, the subwiki. This would allow to had >> only >>>>> scan both the wiki of the user and the target entry to consider our >> cache >>>>> valid. It means subwiki will be unable to share groups (I do not think >>>> this >>>>> has ever worked), but it will keep performance on large farm. >>>>> >>>>> This would really need to be fixed sooner than later otherwise I know >>>>>> plenty of projects for which migration to 5.0 would be almost >> impossible >>>>>> >>>>> >>>>> I will need helps to achieve that for 5.0 >>>> >>>> ok so before changing anything we need a plan i.e. someone volunteering >> to >>>> work on this, right? >>>> >>> >>> Do we really need that for 5.0 ? >>> Using the new module as a default does not means the old right service is >>> unavailable. Couldn't we simply define which case needs to revert to the >>> old modules in the RN, and have 5.0 without this feature ? We may even >>> release XEM without it if workspace need so. >> >> I thought the config change you were proposing was global… I'm lost… >> > > It was, but I was not aware that workspace may need (to be confirmed) that > special unsupported case.
I don't see why you consider this use case as special, when all the users are managed in the main wiki and you want local admins to be able to manage groups in their wiki you need this. Or am I missing something ?
I probably expressed myself badly. This is currently unsupported in the new module. I am just saying that even if we release a 5.0 with this regression, a simple like in xwiki.cfg will put back the old right service for those who need this. First, only XEM is impacted, second only user with this kind of delegation need that. So, this is not the general case IMO.
Sure but it's not that simple. We certainly don't want users to be in a situation where their wiki doesn't work, then they spend time trying to understand. After a few days they post to the list and then only change the config property. This will be bad for us. It has to work. Of course we could put it in the Release Notes but it won't help much in practice.
I'd prefer that we have someone committed to work on this before we change the default so that we're sure someone is going to work on this.
In the meantime, maybe you could start a branch where you have it by default so that we can start fixing build/tests?
This is really a lot of works for just a single line commit (redefining all jenkins modules for the branch) I think everyone has been +1 on the principe to push this new component forward, so I see no point on doing that aside.
I already made some preliminary test on my own machine, here are the results: (a few tests failed whatever the RightService used, however, here is the delta)
UITest: 1 failure, 1 error SeleniumTest: 4 failures Rest: 2 failures Storage: 3 failures WYSIWYG: 3 failures
This does not seems much to me in regards to the change. If you all agree, I would like to commit on master ASAP, so all of you may help fixing those tests.
Thomas proposed to help me fixing and improving tests while I add the missing feature of global user in local group on monday (Good news, I already some code that seems to be working, need to optimize a bit and test thoroughly). If everyone take a minimum of time to help fixing their own tests as needed, I do not see why we could not be ready for 5.0M2. And this leave us some more time to fix potential hidden issue before RC.
So, do you agree to go that way and give this long awaited improvement a real boost ?
+1. I'll help fixing the failing tests.
Thanks, Marius
Thanks -Vincent
See my reply to Ludovic for more about how we need to work on that missing feature.
JV.
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Hi Denis, On Fri, Mar 15, 2013 at 12:25 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:57 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:50 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 10:47 AM, Vincent Massol <[email protected]> wrote:
On Mar 15, 2013, at 10:33 AM, Denis Gervalle <[email protected]> wrote:
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
> On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter < [email protected] >> wrote: > >> Hi Denis, >> >> Le 14/03/13 22:59, Denis Gervalle a écrit : >> >> On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote: >>> >>> Hi devs, >>>> >>>> We have a new (component based) authorization module since a
while
now, >>>> and I think 5.0 is the perfect time to introduce it as the default > right >>>> service. First, I simply propose to change the default in xwiki.cfg: >>>> >>>> >>>> >
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
>>>> internal.**XWikiCachingRightService >>>> >>>> (Later, I propose that we deprecate that bridge and that we create a >>>> friendly (xwiki oriented) interface over the more generic >>>> org.xwiki.security.**authorization.**AuthorizationManager. But leave >>>> this for a >>>> later proposal.) >>>> >>>> So this vote is about changing the default in xwiki.cfg before 5.0M2. >>>> >>>> pros: >>>> - improved performance, since the new service is using caching >>>> techniques >>>> and a single page load required lots of calls to it. >>>> - ability for extension to add new rights >>>> - define right declaratively >>>> - separate method for checking and verifying right (throws opposed to >>>> boolean return) >>>> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as >>>> some unstated ones >>>> >>>> Also XWIKI-4550 >>> >>> - possibility to easily solve issues like XWIKI-4491 >>>> - no more admin right per default >>>> - being in good position to improve it and release dependencies to >>>> oldcore for security matters. >>>> - possibility for third party to adapt the right settler to their >>>> special >>>> needs (right decision is plugable) >>>> - a consistant right evaluation with very few exception that could be >>>> explained and documented >>>> >>>> cons: >>>> - no more admin right per default, but since we have DW, the initial >>>> setup is no more a problem, and advanced users may use superadmin. >>>> - groups are only checked from the user wiki, not from the accessed >>>> entity wiki. >>>> >>> >> This sound like a big regression. >> >> Can you explicit more ? Does this mean that adding a global (main wiki) >> user in a local group has no effect ? >> > > You have got it right. This could be improved, and help is welcome. What > happen is that the user groups are evaluated independently to the targeted > entity, and therefore only in the user wiki. > > I admit this is a regression, but I have not cross lots of use case like > those. The simple display in admin of Global user in local Group is even > broken (double xwiki:xwiki:...) so this does not seems to me a common > usage. > You may provide access to global group in a local wiki to achieve the same > goals. > > This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned, and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
ok so before changing anything we need a plan i.e. someone volunteering to work on this, right?
Do we really need that for 5.0 ? Using the new module as a default does not means the old right service is unavailable. Couldn't we simply define which case needs to revert to the old modules in the RN, and have 5.0 without this feature ? We may even release XEM without it if workspace need so.
I thought the config change you were proposing was global… I'm lost…
It was, but I was not aware that workspace may need (to be confirmed) that special unsupported case.
As JV and other have already mentioned, this is not a special use case at all. You also need to consider the fact that with the virtual=1 by default, we are basically moving to XEM as the default product instead of XE, so this feature is becoming more important. In a multiwiki environment, you basically have 2 major use cases: 1) Farm use case, where each wiki is isolated and manages its own local users and does not interact with other wikis 2) Workspaces(intranets/etc.) use case, where the main wiki is the entry point and it is in charge of managing the users and the subwikis are shared locations where global users work on. This means that they need to be given access to those wikis, based on their needs, and this implies that global users need to become members of local groups (subwiki:XWiki.XWikiAllGroup). The alternative of giving individual (per-user) wiki-level rights (in each subwiki) is just not practical. Hope this helped, Eduard I am just saying that while I would like the new module as a default, this
does not prevent a user to use the old one until we properly support that particular feature.
Thanks -Vincent
WDYT ?
Thanks -Vincent
This would really need to be fixed sooner than later otherwise I
know
plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
> >> >> Jérôme >> >> >> - may exhibit some other minor differences compare to existing >>>> implementation (but mostly consistency fixes) >>>> - test could be improved, critical part (right, settler, data >>>> structure, >>>> cache) are covered at almost 100%, api at 60%, this is probably better >>>> than the old right service >>>> - documentation should be improved, but this is not worse than the > old >>>> one anyway >>>> >>>> Since I use the new module in all my production servers for several >>>> months >>>> with success, and I really think that if we do not do it now we will >>>> never >>>> go ahead, here is my big +1 >>>> >>>> WDYT ?
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Le 15/03/13 10:33, Denis Gervalle a écrit :
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]> wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]
wrote: Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.**rightsclass=org.xwiki.**security.authorization.**
internal.**XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.**authorization.**AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones
Also XWIKI-4550 - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki.
This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the targeted entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the same goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^ I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned,
Can you explain why we would need to do that in this case ? Jérôme.
and I would really like to avoid that to happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
This would really need to be fixed sooner than later otherwise I know plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<; http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Mar 15, 2013 at 2:22 PM, Jerome Velociter <[email protected]>wrote:
Le 15/03/13 10:33, Denis Gervalle a écrit :
On Fri, Mar 15, 2013 at 3:12 AM, Ludovic Dubost <[email protected]>
wrote:
2013/3/14 Denis Gervalle <[email protected]>
On Thu, Mar 14, 2013 at 11:12 PM, Jerome Velociter <[email protected]
wrote: Hi Denis,
Le 14/03/13 22:59, Denis Gervalle a écrit :
On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]>
wrote:
Hi devs,
> We have a new (component based) authorization module since a while > now,
and I think 5.0 is the perfect time to introduce it as the default
> right
service. First, I simply propose to change the default in xwiki.cfg:
> > > > xwiki.authentication.****rightsclass=org.xwiki.**** security.authorization.**
internal.****XWikiCachingRightService
> > (Later, I propose that we deprecate that bridge and that we create a > friendly (xwiki oriented) interface over the more generic > org.xwiki.security.****authorization.****AuthorizationManager. But > leave > this for a > later proposal.) > > So this vote is about changing the default in xwiki.cfg before 5.0M2. > > pros: > - improved performance, since the new service is using caching > techniques > and a single page load required lots of calls to it. > - ability for extension to add new rights > - define right declaratively > - separate method for checking and verifying right (throws opposed > to
boolean return)
> - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well > as
some unstated ones
> > Also XWIKI-4550 > - possibility to easily solve issues like XWIKI-4491
> - no more admin right per default > - being in good position to improve it and release dependencies to > oldcore for security matters. > - possibility for third party to adapt the right settler to their > special > needs (right decision is plugable) > - a consistant right evaluation with very few exception that could > be
explained and documented
> > cons: > - no more admin right per default, but since we have DW, the > initial
setup is no more a problem, and advanced users may use superadmin.
> - groups are only checked from the user wiki, not from the > accessed > entity wiki. > > This sound like a big regression.
Can you explicit more ? Does this mean that adding a global (main wiki) user in a local group has no effect ?
You have got it right. This could be improved, and help is welcome. What happen is that the user groups are evaluated independently to the
targeted
entity, and therefore only in the user wiki.
I admit this is a regression, but I have not cross lots of use case like those. The simple display in admin of Global user in local Group is even broken (double xwiki:xwiki:...) so this does not seems to me a common usage. You may provide access to global group in a local wiki to achieve the
same
goals.
This looks to be indeed a big regression. It's quite a common use case to have only global users and to create groups in the local wiki that refer to local users.
^^^^^^^^
I suppose you means global users here.
IMHO, having user managed by a separate entity (global admin), and these same individual users grouped by another one (local admin) is very uncommon delegation of authority to me (but I may be wrong). On the other hand, having a local admin providing access to local ressources to global group (and potentially some global users) makes more sense. In that way, the same admin manage its users, and group its users, and the local admin trust the global admin to know its users.
That said, I am not against any improvement on the way it works, if it is a common use case (moreover used by workspace), we should obviously support it. However, I am convince that evaluating groups based on both the user and the targeted entity is not easily achievable and conduct to very complex partial caching.
I have currently not implemented in the security module anything that would cause all wikis to be scanned,
Can you explain why we would need to do that in this case ?
Since it cache all security decisions, it also need to keep track of user and groups to evict those decisions when some event happen to them. The simplest would be to know for sure all groups a user is in, so we know the user is complete or missing from the cache. This would require scanning all wikis to discover local groups. Obviously, this risk to be really poor on performance, so I need to introduce support for "partial" caching of users relations with groups. And I propose to think about it at wiki level, so we know it will know it have information for this user in a given set of subwiki. To take a right decision, it will need the user to be cached for the main wiki, and the wiki the entity is in.
Jérôme.
and I would really like to avoid that to
happen. So, it will be difficult to avoid partial caching, but we need to limit that at the higher level, the subwiki. This would allow to had only scan both the wiki of the user and the target entry to consider our cache valid. It means subwiki will be unable to share groups (I do not think this has ever worked), but it will keep performance on large farm.
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I will need helps to achieve that for 5.0
This would really need to be fixed sooner than later otherwise I know
plenty of projects for which migration to 5.0 would be almost impossible
I think even Workspaces is using that so XEM by default would fail with this.
Ludovic
Jérôme
- may exhibit some other minor differences compare to existing
implementation (but mostly consistency fixes) > - test could be improved, critical part (right, settler, data > structure, > cache) are covered at almost 100%, api at 60%, this is probably > better
than the old right service
> - documentation should be improved, but this is not worse than the > old
one anyway
> > Since I use the new module in all my production servers for several > months > with success, and I really think that if we do not do it now we will > never > go ahead, here is my big +1 > > WDYT ? > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > > > ______________________________****_________________ devs mailing list [email protected] http://lists.xwiki.org/****mailman/listinfo/devs<http://lists.xwiki.org/**mailman/listinfo/devs> <
http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO ______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost ______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
______________________________**_________________ devs mailing list [email protected] http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 for the idea in general. I'm sure there'll be details to iron out (as pointed out by Jerome and Ludovic). Maybe a first step (if you haven't already done so) would be to enable it on your machine (or somewhere else) and build the full codebase to see if all tests pass. I know quite a few functional that I know will fail and will need to be updated but they're easy to fix. As part of this move I'd like that the old auth code be moved to legacy modules too. But for that to happen we need that friendly xwiki-oriented interface. Without that we won't be able to update our code to use the new module. Do you plan to move the security module to commons too? Thanks -Vincent On Mar 14, 2013, at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Mar 15, 2013 at 8:42 AM, Vincent Massol <[email protected]> wrote:
+1 for the idea in general. I'm sure there'll be details to iron out (as pointed out by Jerome and Ludovic). Maybe a first step (if you haven't already done so) would be to enable it on your machine (or somewhere else) and build the full codebase to see if all tests pass. I know quite a few functional that I know will fail and will need to be updated but they're easy to fix.
I will work on that now, since most seems now favorable to this move.
As part of this move I'd like that the old auth code be moved to legacy modules too. But for that to happen we need that friendly xwiki-oriented interface. Without that we won't be able to update our code to use the new module.
We may move the old implementation right now (but not sure we need too be in hurry for that). The new module expose the bridge (that I would like to mark deprecated as soon as we have an xwiki-oriented interface), so only the API needs to be kept temporarily. Regarding the xwiki-oriented interface, the main work is to define it, and I would like to have others participating in that specs. Writing it should be quite easy.
Do you plan to move the security module to commons too?
It is not impossible on mid-terms. It depends what we intent to achieve. What really link the module to XWiki is the structure of MainWiki-SubWiki-Space-Document. And I have used some specialized EntityReference (SecurityReference, UserSecurityReference and GroupSecurityReference) to support that easily. However, it should not be too complex to abstract more these SecurityReference. That said, supporting global users in local groups goes to less abstractions, and imply the module to knows more about the first two level (MainWiki-SubWiki) than it does currently.
Thanks -Vincent
On Mar 14, 2013, at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this
for a
later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 to do the switch right now but I think we need to support global users in local groups in 5.0, need to be confirmed but I'm pretty sure it's used in Workspaces. On Thu, Mar 14, 2013 at 9:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 to try it out in 5.0M2. Thanks, Marius On Thu, Mar 14, 2013 at 10:20 PM, Denis Gervalle <[email protected]> wrote:
Hi devs,
We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg:
xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService
(Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.)
So this vote is about changing the default in xwiki.cfg before 5.0M2.
pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented
cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway
Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1
WDYT ?
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Caleb James DeLisle -
Denis Gervalle -
Eduard Moraru -
Jean-Vincent Drean -
Jerome Velociter -
Ludovic Dubost -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol