[xwiki-devs] What is the right way to implement XWiki custom permission check in java code?
I have a separate application which has its own users and permission system. I would like to restrict access to some xwiki spaces according to my app permissions. I overrided XWikiCachingRightService class and use checkAccess(String action, XWikiDocument doc, XWikiContext context) function. The problem I have is it's impossible to restrict access to search with this approach. I only need to restrict access to spaces with permissions. So, I need somehow make xwiki aware about my permissions (which spaces user can see). What XWiki java class can I use for this? ~ -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Andrey, Overwriting XWikiCachingRightService is definitely a wrong approach, since this class is only a legacy bridge to support module that was using the old right authorization system. The actual component that effectively respond to authorization request is the AuthorizationManager. You should have a look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module for a detailed description of the security module. The role that really take the decision is the AuthorizationSettler, and it bases his decisions from security rules received from the SecurityEntryReader. Be careful that all rules and decisions are cached based on the entity references, and that you may need to implement a SecurityCacheRulesInvalidator to evict nodes that are no longer valid. Regards, On Fri, Apr 8, 2016 at 11:08 AM, abtv <[email protected]> wrote:
I have a separate application which has its own users and permission system. I would like to restrict access to some xwiki spaces according to my app permissions. I overrided XWikiCachingRightService class and use checkAccess(String action, XWikiDocument doc, XWikiContext context) function. The problem I have is it's impossible to restrict access to search with this approach. I only need to restrict access to spaces with permissions. So, I need somehow make xwiki aware about my permissions (which spaces user can see). What XWiki java class can I use for this? ~
-- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
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-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
When I use XWikiCachingRightService I register it in xwiki.cfg file. Where should I register my implementation of ContextualAuthorizationManager interface? What is a relation between ContextualAuthorizationManager and AuthorizationSettler? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... 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#HRights... . 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#HCompo... 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#HOverr... 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 <[email protected]> wrote:
When I use XWikiCachingRightService I register it in xwiki.cfg file. Where should I register my implementation of ContextualAuthorizationManager interface? What is a relation between ContextualAuthorizationManager and AuthorizationSettler?
-- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
Perhaps [1] is what you're looking for. XWiki's security mechanism [2] is tightly bound to internally stored rights, and changing its code allows only minor cosmetic alterations to the decision process. PhenoTips' "authorization" mechanism [3] makes things extremely modular: you're free to implement as many modules you want, and each module is free to decide in whatever way how rights are given. All you have to do is write a component that implements AuthorizationModule [4]. All available modules are active, and they're chained based on their priority [5]. The authorization manager service [6] calls each module in the descending order of their priority, asking them [7] if a specific action is allowed or not. When asked, each module can either allow (return True), deny (return False), or take no decision and defer to the following modules (return null). The two already implemented modules defer to XWiki's classic security module [8], and take a default (configurable) decision to either allow or deny all so far undecided calls [9]. However, if [8] is active in the system, [9] will never actually be reached, but it is still useful if you decide to remove XWiki's rights altogether. The "bridge" [10] registers this modular authorization mechanism with XWiki, so that it is called instead of the current XWiki security mechanism. All you have to do is set [11] as the rights class in xwiki.cfg: xwiki.authentication.rightsclass=org.phenotips.security.authorization.ModularRightServiceImpl Based on this mechanism, we have several modules that deal with specific rights restrictions: [12] allows to lock a document, preventing all edits, even from administrators, until the document is unlocked again. [13] allows assigning documents to "Projects", giving rights to project owners over those documents. [14] allows setting a document owner, who then is given all access on that document. And more optional modules will be added. [1] https://github.com/phenotips/phenotips/tree/master/components/security [2] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... [3] https://github.com/phenotips/phenotips/tree/master/components/security/autho... [4] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [5] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [6] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [7] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [8] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [9] https://github.com/phenotips/phenotips/blob/master/components/security/autho... [10] https://github.com/phenotips/phenotips/tree/master/components/security/bridg... [11] https://github.com/phenotips/phenotips/blob/master/components/security/bridg... [12] https://github.com/phenotips/phenotips/blob/master/components/record-locking... [13] https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/proj... [14] https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-acces... On 04/12/2016 06:15 AM, Denis Gervalle wrote:
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#HRights... .
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#HCompo... 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#HOverr...
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 <[email protected]> wrote:
When I use XWikiCachingRightService I register it in xwiki.cfg file. Where should I register my implementation of ContextualAuthorizationManager interface? What is a relation between ContextualAuthorizationManager and AuthorizationSettler?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi Sergiu, On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu <[email protected]> wrote:
Perhaps [1] is what you're looking for.
XWiki's security mechanism [2] is tightly bound to internally stored rights, and changing its code allows only minor cosmetic alterations to the decision process.
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:
you're free to implement as many modules you want, and each module is free to decide in whatever way how rights are given. All you have to do is write a component that implements AuthorizationModule [4]. All available modules are active, and they're chained based on their priority [5]. The authorization manager service [6] calls each module in the descending order of their priority, asking them [7] if a specific action is allowed or not. When asked, each module can either allow (return True), deny (return False), or take no decision and defer to the following modules (return null).
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.
The two already implemented modules defer to XWiki's classic security module [8], and take a default (configurable) decision to either allow or deny all so far undecided calls [9]. However, if [8] is active in the system, [9] will never actually be reached, but it is still useful if you decide to remove XWiki's rights altogether.
The "bridge" [10] registers this modular authorization mechanism with XWiki, so that it is called instead of the current XWiki security mechanism. All you have to do is set [11] as the rights class in xwiki.cfg:
xwiki.authentication.rightsclass=org.phenotips.security.authorization.ModularRightServiceImpl
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.
Based on this mechanism, we have several modules that deal with specific rights restrictions:
[12] allows to lock a document, preventing all edits, even from administrators, until the document is unlocked again. [13] allows assigning documents to "Projects", giving rights to project owners over those documents.
I do not really see the benefit, since you can achieve the exact same goal with the current rules available in XWiki.
[14] allows setting a document owner, who then is given all access on that document.
This could be easily implemented using a customization of the CREATOR right.
And more optional modules will be added.
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,
[1] https://github.com/phenotips/phenotips/tree/master/components/security [2]
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... [3]
https://github.com/phenotips/phenotips/tree/master/components/security/autho... [4]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [5]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [6]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [7]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [8]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [9]
https://github.com/phenotips/phenotips/blob/master/components/security/autho... [10]
https://github.com/phenotips/phenotips/tree/master/components/security/bridg... [11]
https://github.com/phenotips/phenotips/blob/master/components/security/bridg... [12]
https://github.com/phenotips/phenotips/blob/master/components/record-locking... [13]
https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/proj... [14]
https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-acces...
On 04/12/2016 06:15 AM, Denis Gervalle wrote:
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#HRights...
.
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#HCompo...
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#HOverr...
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 <[email protected]> wrote:
When I use XWikiCachingRightService I register it in xwiki.cfg file. Where should I register my implementation of ContextualAuthorizationManager interface? What is a relation between ContextualAuthorizationManager and AuthorizationSettler?
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
I received the following error: 2016-04-18 12:46:11,599 [main] ERROR .o.i.DefaultObservationManager - Failed to lookup listeners org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [interface org.xwiki.observation.EventListener] hint = [default]] I implemented the following component: @Component @Named("MyAuthorizationSettler") @Singleton public class MyAuthorizationSettler implements AuthorizationSettler { @Override public SecurityAccessEntry settle(UserSecurityReference userSecurityReference, Collection<GroupSecurityReference> collection, Deque<SecurityRuleEntry> deque) { System.out.println("settle"); System.out.println("name"); System.out.println(userSecurityReference.getName()); System.out.println("space name"); System.out.println(userSecurityReference.getOriginalReference().getLastSpaceReference().getName()); return new SecurityAccessEntry() { @Override public UserSecurityReference getUserReference() { return userSecurityReference; } @Override public SecurityAccess getAccess() { return null; } @Override public SecurityReference getReference() { return null; } }; } } I added the folowing line 0:com.raven.xwiki.auth.RavenAuthorizationSettler to components.txt file. Then I added to xwiki.properties file the following line: security.authorization.settler=com.raven.xwiki.auth.MyAuthorizationSettler What should I need to implement else? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On 04/18/2016 06:03 AM, abtv wrote:
I received the following error: 2016-04-18 12:46:11,599 [main] ERROR .o.i.DefaultObservationManager - Failed to lookup listeners org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [interface org.xwiki.observation.EventListener] hint = [default]]
I implemented the following component:
@Component @Named("MyAuthorizationSettler") @Singleton public class MyAuthorizationSettler implements AuthorizationSettler {
@Override public SecurityAccessEntry settle(UserSecurityReference userSecurityReference, Collection<GroupSecurityReference> collection, Deque<SecurityRuleEntry> deque) { System.out.println("settle"); System.out.println("name"); System.out.println(userSecurityReference.getName()); System.out.println("space name");
System.out.println(userSecurityReference.getOriginalReference().getLastSpaceReference().getName());
return new SecurityAccessEntry() { @Override public UserSecurityReference getUserReference() { return userSecurityReference; }
@Override public SecurityAccess getAccess() { return null; }
@Override public SecurityReference getReference() { return null; } }; } }
I added the folowing line 0:com.raven.xwiki.auth.RavenAuthorizationSettler to components.txt file.
Then I added to xwiki.properties file the following line: security.authorization.settler=com.raven.xwiki.auth.MyAuthorizationSettler
What should I need to implement else?
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/
yes, actual name is RavenAuthorizationSettler, so error message and java class are the same. I just renamed it before (just not depend on real name) Docs say: The component hint of the AuthorizationSettler may be configured from the ConfigurationSource (xwiki.properties) using the key security.authorization.settler. The default hint "default" is implemented by the DefaultAuthorizationSettler. What is hint in this context? -- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On 04/18/2016 11:28 AM, abtv wrote:
yes, actual name is RavenAuthorizationSettler, so error message and java class are the same. I just renamed it before (just not depend on real name)
Docs say: The component hint of the AuthorizationSettler may be configured from the ConfigurationSource (xwiki.properties) using the key security.authorization.settler. The default hint "default" is implemented by the DefaultAuthorizationSettler.
What is hint in this context?
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/
Hi Andrey, I confirm Sergiu answer. As a matter of code style, in your case I would probably put: @Named(“raven”) at the top of your component, and therefore security.authorization.settler=raven in xwiki.properties. The pristine war from XWiki also contains a settler hinted “priority” and implemented by the PrioritizingAuthorizationSettler class, if you have a doubt with your ability for changing the configuration setting, it could be a way to test it, and also a way to compare against your own customization. Please note that this “priority” settler is experimental. Regards, On Mon, Apr 18, 2016 at 12:03 PM, abtv <[email protected]> wrote:
I received the following error: 2016-04-18 12:46:11,599 [main] ERROR .o.i.DefaultObservationManager - Failed to lookup listeners org.xwiki.component.manager.ComponentLookupException: Failed to lookup component [role = [interface org.xwiki.observation.EventListener] hint = [default]]
I implemented the following component:
@Component @Named("MyAuthorizationSettler") @Singleton public class MyAuthorizationSettler implements AuthorizationSettler {
@Override public SecurityAccessEntry settle(UserSecurityReference userSecurityReference, Collection<GroupSecurityReference> collection, Deque<SecurityRuleEntry> deque) { System.out.println("settle"); System.out.println("name"); System.out.println(userSecurityReference.getName()); System.out.println("space name");
System.out.println(userSecurityReference.getOriginalReference().getLastSpaceReference().getName());
return new SecurityAccessEntry() { @Override public UserSecurityReference getUserReference() { return userSecurityReference; }
@Override public SecurityAccess getAccess() { return null; }
@Override public SecurityReference getReference() { return null; } }; } }
I added the folowing line 0:com.raven.xwiki.auth.RavenAuthorizationSettler to components.txt file.
Then I added to xwiki.properties file the following line: security.authorization.settler=com.raven.xwiki.auth.MyAuthorizationSettler
What should I need to implement else?
-- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
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-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
On Tue, Apr 19, 2016 at 11:55 AM, abtv <[email protected]> wrote:
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?
That’s right, you get it :)
-- View this message in context: http://xwiki.475771.n2.nabble.com/What-is-the-right-way-to-implement-XWiki-c... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
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-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Andrey, On Tue, Apr 19, 2016 at 4:51 PM, abtv <[email protected]> wrote:
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.
For access to the XWikiContext, you may @Inject a Provider<XWikiContext> in your settler directly, as well as any other XWiki component you might need. However, if you just needs to access the request, it could be better to do so by @Inject-ing a org.xwiki.container.Container, which give you this access without requiring you to depend on the oldcore package. It really depends on your needs and actual dependency, and the above is true about any component you might need.
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?
There is no configuration for that component, but overriding should be done like what is possible with any other component. So, this is harder than just a configuration here, you need to override the original DefaultSecurityCacheRulesInvalidator by providing another “default” implementation of the SecurityCacheRulesInvalidator. You can either use the prioritization of components that I mentioned earlier (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HOverr...) or manage your registration “by hand” http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HCompo..., for example during the initialization of your settler, depending on how you expect to inject yourself in the system. See also my earlier reply about this as well. Regards, -- Denis Gervalle SOFTEC sa - CEO
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-c... Sent from the XWiki- Dev mailing list archive at Nabble.com.
participants (3)
-
abtv -
Denis Gervalle -
Sergiu Dumitriu