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 <dmitry.gu...@gmail.com>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 <
> kalle.o.korho...@gmail.com> 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 <dmitry.gu...@gmail.com>
>> 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: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
