Hi I have added some comments to your explanations.
On Wed, Nov 10, 2010 at 11:55 AM, Reto Bachmann-Gmuer <[email protected]> wrote: > Hi Tsuy > > You're right that its probably not possible to have the permssions > based on code-base, as the invoked service has its usual code-base. So > maybe just making sure ssp are executed as anonymous independently on > a logged in user. However that way an ssp could still do things as > priviledged. As far as I know, executing ssps as anonymous would have side effects to enrichment providers (implementation of org.apache.clerezza.platform.enrichment.EnrichmentTcProvider.java). e.g. data which are used to enrich resources are stored in a dedicated graph/database (only admins have permissions to read this graph and should get this information). if ssps are executed as anonymous parts of the enrichment provider has to be enclosed in a "doPrivileged" block and thus all users can get to this data. > > The other two variants are independent of the permission system. Th > first one would go like this: > > if a Service Interface is annotated with @AvailableFromSsp (or > @SideEffectFree) then it is available with something like > $[org.example.ServiceInterface] other not. > > At the cost of more complexity (dynamic proxies) I think it would also > be possible to annote single methods as @SideEffectFree, so > $[org.example.ServiceInterface].getValue() would work, but > $[org.example.ServiceInterface].clear() would throw an Exception. > > Are things clearer now? Yes, thank you. I prefer alternative 2: services should be annotated to be available in ssps. Tsuy
