> 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).
Yes, that's exactly what it does - I will take with your method name. > ... > >> // 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. That's okay for me > > >>... 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. It's not really an optimization in the sense of a QueryOptimizer, that could be done by every ResourceProvider by now, without any new API. The sanitizeQuery functionality has to come with the ResourceAccessSecurity service: The query can be injected (sanitized) only from a service which "knows" the security rules for the given user. If you look at the example above with the injection "WHERE owner=<user>": This could only be injected by a service which knows that the given user only has access to resources where the he is the owner. Maybe a different user with more rights does not have any restrictions (or another restriction). I do have experience with such a possibility of query injection for years now and can say that it speeds up access controlling a lot. best regards Mike
