On 06/04/2013 11:03 AM, Dmitry Gusev wrote:
Just a note that you always can write your own component like this if you
want:
<t:hasPermission2 permission="some:permission" instance="myInstance">
That's probably the better long term solution for my environment.
On Tue, Jun 4, 2013 at 7:50 PM, Richard Frovarp <rfrov...@apache.org> wrote:
That would work. The trick is that I need to compute the permissions
dynamically. I'll have to add in more code to handle those types of
wildcard permissions. I was hoping for something much more similar to what
I can use with the @RequiresPermissions check. But since I don't have an
invocation, that looks like what I'll have to do.
I'm not sure I understand you, how would this differ from the case with
MethodInvoication?
Isn't the same AuthorizingRealm will check permissions for you?
Just check if your permission has targets set and if it has - you can just
peek instance from them.
If not - try to get if from MethodInvoication.
Anyway, if you need that invocation - you can create one - just call some
method from your new component newPermission2 and intercept that call with
@RequiresPermissions. But you can't declare dynamic permission in the
annotation, you do understand this, right?
By using the MethodInvocation (and perhaps actually getting the
instance), I get the object to inspect directly, instead of having to
get Cayenne to retrieve it for me via the object id.
What I've done is to create a realm that uses reflection / introspection
to find methods annotated with a special annotation. The string in that
annotation matches exactly with the permission being checked. When
permission checks come in, they are dispatched to the method marked as
being responsible for that permission.
So this:
@RequiresPermissions(ILACAuth.SERVICE_MANAGE_VIEW_INSTANCE)
public void onActivate(Service service) {
ends up getting processed by this:
@InstanceAccessMethod(ILACAuth.SERVICE_MANAGE_VIEW_INSTANCE)
public boolean isPermittedViewService() {
MethodInvocation methodInvocation = getInvocation();
if (methodInvocation == null) {
return false;
}
Object instance = methodInvocation.getInstance();
...
}
Where the permission is: servicemanager:view:instance.
This idea works everywhere, except for template rendering. I do support
passing in the permission being checked when dispatching the call. I
just need to get around the exact string matching I'm doing. This will
probably require a locally reserved word in the permission to make it work.
So to handle the template scenario, I probably need to do something
like: servicemanager:view:instance:key:265 and then know to chop :key on
to dispatch to the correct check, and pass the permission in so it can
have Cayenne retrieve the correct record if necessary. My method would
have to change as well. It's not insurmountable, it just requires more
work to set everything up.
The key thing is I now understand that I can't get what I need via
MethodInvocation when rendering, so I don't bang my head against that wall.
Thanks,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
