What is the right way to implement XWiki custom permission check in java code?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the right way to implement XWiki custom permission check in java code?

abtv
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?
~                                      
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
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 <[hidden email]> 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-custom-permission-check-in-java-code-tp7598878.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
In reply to this post by Denis Gervalle-2
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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
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#HRightsandaccessdecisions
.

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#HComponentRegistration
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#HOverrides

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 <[hidden email]> 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-custom-permission-check-in-java-code-tp7598878p7598933.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Sergiu Dumitriu-3
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/xwiki-platform-security
[3]
https://github.com/phenotips/phenotips/tree/master/components/security/authorization
[4]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java
[5]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L48
[6]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationService.java
[7]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L59
[8]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/XWikiACLAuthorizationModule.java
[9]
https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/BaseAuthorizationModule.java
[10]
https://github.com/phenotips/phenotips/tree/master/components/security/bridge
[11]
https://github.com/phenotips/phenotips/blob/master/components/security/bridge/src/main/java/org/phenotips/security/authorization/ModularRightServiceImpl.java
[12]
https://github.com/phenotips/phenotips/blob/master/components/record-locking/api/src/main/java/org/phenotips/recordLocking/internal/authorization/LockedAuthorizationModule.java
[13]
https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/projects/api/src/main/java/org/phenotips/projects/authorization/ProjectAuthorizationModule.java
[14]
https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-access-rules/api/src/main/java/org/phenotips/data/permissions/internal/OwnerAccessAuthorizationModule.java

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#HRightsandaccessdecisions
> .
>
> 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#HComponentRegistration
> 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#HOverrides
>
> 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 <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
Hi Sergiu,

On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu <[hidden email]> 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/xwiki-platform-security
> [3]
>
> https://github.com/phenotips/phenotips/tree/master/components/security/authorization
> [4]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java
> [5]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L48
> [6]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationService.java
> [7]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/AuthorizationModule.java#L59
> [8]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/XWikiACLAuthorizationModule.java
> [9]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/authorization/src/main/java/org/phenotips/security/authorization/internal/BaseAuthorizationModule.java
> [10]
>
> https://github.com/phenotips/phenotips/tree/master/components/security/bridge
> [11]
>
> https://github.com/phenotips/phenotips/blob/master/components/security/bridge/src/main/java/org/phenotips/security/authorization/ModularRightServiceImpl.java
> [12]
>
> https://github.com/phenotips/phenotips/blob/master/components/record-locking/api/src/main/java/org/phenotips/recordLocking/internal/authorization/LockedAuthorizationModule.java
> [13]
>
> https://github.com/phenotips/phenotips/blob/PT-1987-projects/components/projects/api/src/main/java/org/phenotips/projects/authorization/ProjectAuthorizationModule.java
> [14]
>
> https://github.com/IJessa/phenotips/blob/issue-1023/components/patient-access-rules/api/src/main/java/org/phenotips/data/permissions/internal/OwnerAccessAuthorizationModule.java
>
> 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#HRightsandaccessdecisions
> > .
> >
> > 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#HComponentRegistration
> > 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#HOverrides
> >
> > 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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
This post was updated on .
In reply to this post by Denis Gervalle-2
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? I'm not sure I understand how to set hint (by default it is "default").
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Sergiu Dumitriu-3
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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
This post was updated on .
yes, actual name is RavenAuthorizationSettler, so config and java class are the same. I just renamed it before (just not depend on real name). Is it ok to use 0: to give the highest priority?

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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Sergiu Dumitriu-3
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/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
In reply to this post by abtv
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 <[hidden email]> 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-custom-permission-check-in-java-code-tp7598878p7599032.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
On Tue, Apr 19, 2016 at 11:55 AM, abtv <[hidden email]> 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-custom-permission-check-in-java-code-tp7598878p7599056.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Denis Gervalle
SOFTEC sa - CEO
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

abtv
In reply to this post by Denis Gervalle-2
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?
Reply | Threaded
Open this post in threaded view
|

Re: What is the right way to implement XWiki custom permission check in java code?

Denis Gervalle-2
In reply to this post by abtv
Hi Andrey,

On Tue, Apr 19, 2016 at 4:51 PM, abtv <[hidden email]> 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#HOverrides)
or manage your registration “by hand”
http://extensions.xwiki.org/xwiki/bin/view/Extension/Component+Module#HComponentRegistration,
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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs