Hi, Denis, thanks for your answer, but I can't understand how to implement custom access checking. Should I implement AuthorizationManager methods? If so, where is xwiki.properties or xwiki.cfg setting to use my custom class? If not, what should I implement? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

Hi Andrey, I would not advice to reimplement the ContextualAuthorizationManager, since it only provide context to the AuthorizationManager, and there is probably no need for you to change that part. I would not even advice to reimplement the AuthorizationManage (since the way it works provide some useful caching mechanism using the security cache), unless you really want to revamp the way rights are managed. This could be a lot of work, while there is a lot of room for customizing rights and the way these are interpreted. The AuthorizationSettler, which receive information from the wiki (security rules) and take the decision is probably the easiest place where you can change the way decision are taken. Moreover, this one is configurable in xwiki.properties, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HRight… . If your need is better solved by injecting custom security rules, you may also want to override the bridge part. The security module is completely agnostic to XWiki itself, and the junction is made by the security bridge module. This where you will found the default SecurityEntryReader. When you need to override a component that does not have a dedicated configuration, during your development or when installed as an extension, you have to unregister the existing component (to be polite), and register yours in replacement, see http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HComp… about component registration. If you end up packaging the component in a custom war, you may want to use the priority override solution, as describe in http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOver… I hope this answer your questions, I encourage you to read the Javadoc of the security module for explanation about each roles and how they could influence the whole system, as I said, a lot can be done without having to rewrite the whole thing, which is a tough task. Regards, On Tue, Apr 12, 2016 at 10:16 AM, abtv <andreybutov(a)mail.ru> wrote: -- Denis Gervalle SOFTEC sa - CEO

Hi Sergiu, On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu <sergiu(a)xwiki.org> wrote: This is a bit harsh. You seems to have missed an important goal of the rewrite of the right system I did. Available since version 4.x and integrated in XWiki 5.0 and later, our complete rewrite of the security authorization module allows custom definition of new rights, full customization of the authorization decision process, and is almost entirely disconnected from the XWiki platform (the only reason it is not in commons, is just the EntityReference related stuffs). The new module not only provide several entry points for customization, it also provide a very efficient security cache. The new module is articulated around the AuthorizationManager which provide a very generic authorization checking interface, SecurityRules that provide a generic definition of security access rules, and an AuthorizationSettler which is pluggable and responsible for all final decision. Injecting rules into the system could be done by reimplementing a different SecurityEntryReader, but if you want, you may as well benefit of all the infrastructure provide by the wiki while managing rights in a very different manner simply by providing a different authorization settler. PhenoTips' "authorization" mechanism [3] makes things extremely modular: This seems to be about allowing to have several authorization managers. It would be interresting to see why you felt you needed that. It would have been nice to bring the subject on the mailing list before doing it on your side since it seems to be simple enough to be integrated in standard if really needed. Hopelessly, this is wrong. This configuration option is deprecated since XWiki 5.x, and should no more be used to hook the XWiki authorization system. Here is the excerpt from the configuration file: #-# (Deprecated) The authorization management class. #-# [Since 5.0M2] The default right service is now org.xwiki.security.authorization.internal.XWikiCachingRightService #-# which is a bridge to the new security authorization component. It provides increased security and performance, but #-# its right policies differ sightly from the old Right Service implementation. In rare situation, you may want to #-# switch back to the old unmaintained implementation by uncommenting the following line. However, only old #-# implementation, still using a bridged RightService will be impacted by this parameter. Customization of the new #-# security authorization component should be done in the new xwiki.properties configuration (security.*). While in XWiki 5.x, most of the xwiki services were still using the old RightService, and so you were capturing more than 90% of the security checks, as more time and version passes, you are capturing less and less of these call, and in a future I do not expect too far, none of them. The new component use for security authorization checks is now the ContextualAuthorizationManager, which is a context based version of the AuthorizationManager, and more and more XWiki components are now targeting those two components directly, fully bypassing the legacy XWikiRightService interface. Therefore, by no means, you can really capture the authorization service using the above configuration change. I do not really see the benefit, since you can achieve the exact same goal with the current rules available in XWiki. This could be easily implemented using a customization of the CREATOR right. I admit that there are still room for improvement as usual in our new security module, and I would be pleased to receive your contribution. But please, stop saying that our actual implementation could only be used for minor cosmetic alterations of the decision process. Thanks in advance for your understanding, -- Denis Gervalle SOFTEC sa - CEO

On 04/18/2016 06:03 AM, abtv wrote: Quick check, the code says "MyAuthorizationSettler" but the configuration says "RavenAuthorizationSettler". Is that wrong in the email only, or in the actual code? -- Sergiu Dumitriu http://purl.org/net/sergiu/

On 04/18/2016 11:28 AM, abtv wrote: The hint is what you put here: @Named("MyAuthorizationSettler") So try this: security.authorization.settler=MyAuthorizationSettler (or RavenAuthorizationSettler if you also changed the hint of the class) Note that the actual cause of the problem is near the end of the stacktrace, the first one is just the tip of the iceberg that doesn't provide any useful debugging information. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Yes, it works now. Great thanks! Looks like I need to implement SecurityCacheRulesInvalidator and reset rules when my model changes and that's it. No need to change something else, right? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

A couple more questions. 1. When I used my own implementation of XWikiCachingRightService I had access to XWikiContext (there is getRequest method and I could send request to the server with the same cookie) and I sent a request to my main app to get data. Can I get access to underlying request data in settler? I need a way to ask my main app about current permission. Can I use REST call inside settler? And it would be great if I can do it with credentials of current user. 2. Regarding SecurityCacheRulesInvalidator. Should I register my implementation of SecurityCacheRulesInvalidator in xwiki.properties or xwiki.cfg files? Or it should be only components.txt file where I registered other components? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-… Sent from the XWiki- Dev mailing list archive at Nabble.com.

I've spent some time studying docs and source code and can't understand how to invalidate cache properly. First of all, there are suspend and resume methods in SecurityCacheRulesInvalidator interface. As I understand, my component should call suspend method, invalidate cache and then call resume method, right? The question is how I should pass cache component to my component (which implements SecurityCacheRulesInvalidator)? What exactly I should inject? I also can't understand the following. When my main app changes permissions they are stored to a separate database. How can I make xwiki aware about these changes? What is the best way to communicate between 2 applications for this task? O Maybe there is a way to disable caching for some patterns: don't cache urls where space name is not on a list of predefined strings. If space name is on the list (it could be xwiki own spaces, like themes, etc), then we use cache, overwise we call settle every time (for my own spaces). Is it possible? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-… Sent from the XWiki- Dev mailing list archive at Nabble.com.