> > 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).... > > This sounds scary to me in terms of security, with many moving parts. > I guess I'll need to see more concrete examples to make up my mind.
It shouldn't scare at all: With or without the use of sanitizeQuery, the resulting list of resources (or the resulting resource) is checked against security anyway. So sanitizeQuery does not disturb security. The use case is very simple as showed above: If a query returns a lot of resources but the querying user does only have access to a few of these resources, sanitizeQuery could change the query in a way that only a few resources will be returned from the resource provider. Without sanitizeQuery it can take quite a long time to check each and every resource with getReadableResource() if the querying user has read access to the resource. We don't talk about some milliseconds here but about seconds or minutes if there are a lot of similar resources but the user has access only to a few (and the persistence does not have any ACLs - which is the use case for ResourceAccessSecurity). So we really can gain a lot with this method in matters of performance for some cases, but nobody who want's to use ResourceAccessSecurity in the future has to implement it. The disadvantage could be (depends on the data) that applying access rights is slow if someone decides not to impement it. So we only can win with this additional method. Best regards Mike
