On 10/6/06, Ottinger, Joseph <[EMAIL PROTECTED]> wrote:
Ah ha! That's definitely better than I was afraid of... but how does one go about configuring this properly? (Any documentation for mere mortals anywhere?)
jsr-170 (JCR 1.x) does not cover access control management, i.e. assigning and managing access rights is vendor-specific. jsr-283 (JCR 2.x) will probably cover access control management by defining a standard api for managing access rights. jackrabbit supports pluggable custom access control through the AccessControlManager interface. currently there's only a dummy implementation available in jackrabbit, so you'd have to roll your own. cheers stefan
________________________________ From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: Fri 10/6/2006 5:52 AM To: [email protected] Subject: Re: Security problem with QueryManager? On 10/5/06, Ottinger, Joseph <[EMAIL PROTECTED]> wrote: > I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right? > > When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'"; > > Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst. > > Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole. > > Am I missing something? well, unlike databases JCR *does* provide fine-grained access control, i.e. the user will only get those results which he has read-access on. cheers stefan >
