Tim Kettering wrote:
Hi all,
I've been working on incorporating acegi with our project, and with the useful addition of the after invocation stuff that ben added recently, this will help with methods that need to return a collection of objects, each of which need to be inspected for security access.
however, im curious if how (if anyone) has approached doing something like this.
public List getListOfItems(int firstResult, int size) { ... }
The issue I see here is that if I request a list that is 10 items, starting at row one, the method will fetch items 1-10 from the database, then in post invocation, potentially some, or all will be knocked out by the security framework. So the end result would be possibly ten or more likely less than 10 items. And a programmer using the above method would not receive what he/she had been expecting.
So I see a few possible workarounds.. like fetching the next consecutive resultset if some items are knocked out of the original result, and repeating it until we have the desired size - maybe to make things more effiicent, to always fetch a slightly larger set, like 150% more (just a number i picked off my head), so that way a successive fetch would be less likely, or what.
I thought I'd query the list for any ideas/suggestions before I went ahead with this.
-tim
Hi Tim
There's no real way of doing this in Acegi Security. You'll need to use one of the workarounds you mentioned, the main question being where to put that successive fetching logic. It would ideally belong in the services layer, as the same transparency would be required by multiple client types.
I don't think you'll be able to return a standard List, as you need some tracking of what is the "real" ending result number, so it can be used for the next request's firstResult parameter. We use a PaginatedList for paginated lists, which implements List, so you'll have no difficulty with using the BasicAclEntryAfterInvocationCollectionFilteringProvider.
Recall the signature of an AfterInvocationProvider includes:
public Object decide(Authentication authentication, Object object, ConfigAttributeDefinition config, Object returnedObject);
As such, you have access (via the object argument) to the invocation that caused the provider to be called. So a possible alternative might be to write a new AfterInvocationProvider along the lines of BasicAclEntryAfterInvocationCollectionFilteringProvider, but this time it will call the MethodInvocation multiple times to obtain the collection size returned by the original invocation. Off hand I can't think of any problems with this (you can do a ((MethodInvocation)object).getMethod()), although you might run into some issue. This would be the ideal approach, as it's putting the successive fetching logic with the logic that filters the results in the first place.
Best regards Ben
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
