7 messages in org.xwiki.devsRe: [xwiki-devs] [Proposal] QueryMana...
FromSent OnAttachments
Artem MelentyevMay 25, 2008 8:08 am 
Vincent MassolMay 25, 2008 9:03 am 
Artem MelentyevMay 25, 2008 11:18 am 
Vincent MassolMay 25, 2008 12:11 pm 
Vincent MassolMay 26, 2008 2:35 am 
Artem MelentyevMay 28, 2008 5:31 am 
Vincent MassolMay 28, 2008 5:47 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [xwiki-devs] [Proposal] QueryManager in storeActions...
From:Vincent Massol (vinc@massol.net)
Date:May 28, 2008 5:47:02 am
List:org.xwiki.devs

On May 28, 2008, at 2:31 PM, Artem Melentyev wrote:

Hi, Vincent.

Vincent Massol wrote:

4) I'd really like that we try to remove any velocity-specific API so that we have only 1 Java API for all. Maybe we can introduce some velocity tools to handle the cases where you think it is required. What would be those cases?

Main issue are check rights for returned documents

We should probably have 2 Java APIs: one with restricted rights and one with unrestricted rights.

Actually what we have started with Sergiu is to use a @permission annotation (I'm not sure of its exact name) so that we can flag an API as requiring a specific permission.

For example: @permission("admin") @permission("programming") @permission("edit")

However the mechanism to "trust" some components so that they can access some privileged API is different and I think that one could be done using the JVM security policy mechanism.

Some of our org.xwiki components will be able to call the unrestricted rights api (we need to define how that will work - security policy?). But this is not related to Velocity. For example if, as a user, I write a new component I should only be able to call the restricted rights API, unless I have some extra rights set up or unless I modify the "container security policy".

We can create 2 QueryManagers: one with only secure languages, and another with all languages.

Well, this is not related to the query manager but to all our APIs in general so I'm not sure why we would create 2 query managers.

[snip]

Thanks -Vincent