Applied, excellent patch thanks! Kalle
On Thu, Oct 11, 2012 at 3:35 PM, Dmitry Gusev <[email protected]> wrote: > Done: > > http://jira.codehaus.org/browse/TYNAMO-183 > > > On Fri, Oct 12, 2012 at 1:46 AM, Dmitry Gusev <[email protected]>wrote: > >> Using @Core annotation helped: >> >> @Match("*") >> >> @Order("before:*") >> >> public static void adviseSecurityAssert(MethodAdviceReceiver receiver, >> >> final @Core Environment environment) >> >> >> On Fri, Oct 12, 2012 at 12:59 AM, Dmitry Gusev <[email protected]>wrote: >> >>> Ok, I'm working on the patch now. >>> >>> I have a problem injecting Environment instance into advisor method in >>> SecurityModule: >>> >>> @Match("*") >>> >>> @Order("before:*") >>> >>> public static void adviseSecurityAssert(MethodAdviceReceiver receiver, >>> >>> final Environment environment) >>> >>> this issue was already filed in JIRA: >>> >>> https://issues.apache.org/jira/browse/TAP5-1045 >>> >>> >>> Caused by: java.lang.IllegalStateException: Construction of service >>> 'AssetObjectProvider' has failed due to recursion: the service depends on >>> itself in some way. Please check >>> org.apache.tapestry5.internal.services.AssetObjectProvider(AssetSource, >>> TypeCoercer, SymbolSource) (at AssetObjectProvider.java:45) via >>> org.apache.tapestry5.services.TapestryModule.bind(ServiceBinder) (at >>> TapestryModule.java:308) for references to another service that is itself >>> dependent on service 'AssetObjectProvider'. >>> >>> at >>> org.apache.tapestry5.ioc.internal.RecursiveServiceCreationCheckWrapper.createObject( >>> RecursiveServiceCreationCheckWrapper.java:52) >>> >>> >>> >>> On Thu, Oct 11, 2012 at 8:49 PM, Kalle Korhonen < >>> [email protected]> wrote: >>> >>>> Instance-level access control is a very interesting topic to me. I say >>>> you are pretty much on the right track if you want to use the >>>> permission model. You wouldn't *necessarily* need to change anything >>>> in Shiro if you just did programmatic checks with isPermitted and you >>>> knew the right permissions at the time you are creating the >>>> AuthorizationInfo. However, that model is cumbersome as you need to >>>> create all the permissions upfront and then later formulate specific >>>> ones when doing an authorization check - and you still couldn't use >>>> annotations. Alex' syntax is one way to go about and you certainly >>>> need some property substitution syntax for doing instance level checks >>>> with annotations. Using the environment for fetching the >>>> MethodInvocation sounds reasonable and I'm open to adding that as a >>>> patch to tapestry-security. That way everybody at least wouldn't need >>>> to introduce their own annotations. >>>> >>>> Entity-Relationship Based Access control is a completely different >>>> take on the same topic. It's based on the idea that the data objects >>>> you are trying to secure are in one way or another associated to the >>>> currently executing subject. It greatly simplifies the syntax required >>>> but obviously limits the possibilities as well. You wouldn't >>>> necessarily need a "DAO" but still, some single, uniformed way of >>>> accessing the data objects. The current implementation works at the >>>> (JPA) EntityManager level. >>>> >>>> Kalle >>>> >>>> >>>> On Thu, Oct 11, 2012 at 6:38 AM, Dmitry Gusev <[email protected]> >>>> wrote: >>>> > Hi, >>>> > >>>> > I need to implement instance-level access control in my application >>>> using >>>> > tapestry-security. >>>> > >>>> > I already asked similar question here [1]. >>>> > >>>> > There Taha suggested to use AuthorityVoter, but that wasn't Tynamo's >>>> > tapestry-security. >>>> > >>>> > I looked at Entity-Relationship Based Access Control [2]. >>>> > >>>> > This is not exactly what I need, because I don't even have DAO layer >>>> > involved here. >>>> > >>>> > Here's what I have. I have business method in one of my services: >>>> > >>>> > @RequiresPermissions("task:submit") >>>> > >>>> > void submitTask(Task newTask); >>>> > >>>> > I read about ILAC on Shiro's web site [2]. >>>> > >>>> > This looks similar, but in my domain not every user may submit every >>>> task >>>> > for execution. >>>> > I have custom logic that should inspect instance of the newTask and >>>> decide >>>> > whether current user has permissions to submit the task for execution >>>> or >>>> > not. >>>> > >>>> > In Shiro's documentation [3] there's a note that tells that a >>>> developer may >>>> > write its own implementation of AuthorizingRealm.isPermitted(*) to >>>> check >>>> > permissions against custom domain model. I'm not sure about this in my >>>> > case, though, because this note is given in 'Performance >>>> Considerations' >>>> > section. >>>> > >>>> > One more thing that stops me from overriding >>>> AuthorizingRealm.isPermitted(*) is >>>> > I don't have access to invocation context, i.e. I can't get instance >>>> of the >>>> > newTask from example above: >>>> > >>>> > AuthorizingRealm realm = new AuthorizingRealm() >>>> > >>>> > { >>>> > >>>> > @Override >>>> > >>>> > public boolean isPermitted(PrincipalCollection principals, >>>> > Permission permission) { >>>> > >>>> > // XXX ... can't access to newTask instance >>>> > >>>> > } >>>> > >>>> > >>>> > I was thinking about fixing Tynamo's SecurityInterceptor advise, by >>>> putting >>>> > MethodInvocation into Tapestry Environment service instance and getting >>>> > this MethodInvocation from there in realm. >>>> > >>>> > Am I in the right direction? Any suggestions? >>>> > >>>> > >>>> > >>>> > [1] >>>> > >>>> http://tapestry.1045711.n5.nabble.com/ANN-A-Tapestry5-Based-Security-Module-tp3322452p3338137.html >>>> > [2] http://tynamo.org/tapestry-security-jpa+guide >>>> > [3] >>>> > >>>> http://shiro.apache.org/permissions.html#Permissions-InstanceLevelAccessControl >>>> > [4] >>>> > >>>> http://shiro.apache.org/permissions.html#Permissions-PerformanceConsiderations >>>> > >>>> > -- >>>> > Dmitry Gusev >>>> > >>>> > AnjLab Team >>>> > http://anjlab.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> >>> -- >>> Dmitry Gusev >>> >>> AnjLab Team >>> http://anjlab.com >>> >> >> >> >> -- >> Dmitry Gusev >> >> AnjLab Team >> http://anjlab.com >> > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
