Hi Mike, Thanks for your replies - as usual I'm a stickler for names...I think good naming helps a lot in making APIs understandable.
On Mon, Mar 25, 2013 at 8:14 PM, Mike Müller <[email protected]> wrote: ... > Bertrand wrote: >> // Calling that canRead would be more consistent with other names >> public Resource checkReadPermission( Resource resource ); > > I choosed another naming because canCreate, canDelete, etc. returns a boolean, > but checkReadPermission returns a Resource. Maybe it's more visible with > a different methode name. What's the goal of returning a Resource? Is one expected to use the returned one instead of the one that's passed into the method? If yes I'd suggest getReadableResource(Resource). ... >> // Having to extract username as a String feels a bit funny - maybe >> // you need an opaque ResourceCredentials object... > ...At this time ResourceResolver has a method named getUserID() which > returns a String... As Carsten says, passing the ResourceResolver in such cases is probably the best way to provide context. >>... Maybe canSetValue >> // can cover both cases, by first checking if the value exists.. > Yes good point, we could make this easier with just one method. ok >... >> public String sanitizeQuery( String query, String language, String >> user ) throws AccessSecurityException; > ...Think of a mongodb like persistence > layer with millions of resources saved. No we've got a user which has access > to only 10 resources. Now he makes a query like "SELECT * FROM allresources" > (just as an example in an SQL like language). This query would now return > millions of resources and every resource in the returning list would be > checked > by ResourceAccessSecurity#canRead. With sanitizeQuery the query could > be injected with some limiting statements like "SELECT * FROM allresources > WHERE owner=<userid>". In this case a list of only 10 resources would > be returned. Nevertheless every returned resource would be checked by canRead, > but the performance would be much much better than in the first case.... Could this be done by having the ResourceProvider implement a QueryOptimizer API instead? The ResourceResolver can then check if the provider implements this and call that method in that case. It doesn't feel right to me to mix that method with security stuff as it has nothing to do with security AFAICS. -Bertrand
