Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-20 Thread Denis Gervalle
Hi Andrey,

On Tue, Apr 19, 2016 at 4:51 PM, abtv  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 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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-19 Thread 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?



--
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-tp7598878p7599074.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-19 Thread Denis Gervalle
On Tue, Apr 19, 2016 at 11:55 AM, abtv  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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-19 Thread 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?



--
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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-18 Thread Denis Gervalle
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  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 collection,
> Deque 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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-18 Thread Sergiu Dumitriu
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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-18 Thread abtv
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-custom-permission-check-in-java-code-tp7598878p7599039.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-18 Thread Sergiu Dumitriu
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 collection,
> Deque 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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-18 Thread abtv
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 collection,
Deque 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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-12 Thread Denis Gervalle
Hi Sergiu,

On Tue, Apr 12, 2016 at 3:19 PM, Sergiu Dumitriu  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 

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-12 Thread Sergiu Dumitriu
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 

Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-12 Thread Denis Gervalle
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  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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-12 Thread abtv
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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-11 Thread 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?



--
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-tp7598878p7598924.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-08 Thread Denis Gervalle
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  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
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>



-- 
Denis Gervalle
SOFTEC sa - CEO
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


[xwiki-devs] What is the right way to implement XWiki custom permission check in java code?

2016-04-08 Thread 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? 
~   



--
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
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs