[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840756#comment-17840756 ] Radu Cotescu commented on SLING-12300: -- I've updated the PR to include a configuration flag. Let me know what you think. I'd like to get this merged by the end of next week. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840164#comment-17840164 ] Radu Cotescu commented on SLING-12300: -- I’m perfectly fine to have this feature disabled by default, behind a configuration toggle. I’ll update the PR as soon as I find some time to come back to this issue. Thanks! > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840127#comment-17840127 ] Paul Bjorkstrand commented on SLING-12300: -- That's a good analysis, [~radu], thanks for sharing. I understand the Resource API challenges. It makes sense to keep this as a JCR concept. I feel we can drop that idea from contention given its significant constraints. Regarding the other two, maybe there is a way to be able to have the best of both worlds, by making the new {{/jcr:id/}} path available, but behind a configuration flag ({{false}} by default). I think that would allow you to keep the simpler implementation, but also addresses any security/exposure related issues, since it would be an opt-in feature. Thoughts? > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840065#comment-17840065 ] Radu Cotescu commented on SLING-12300: -- Let's compare the three options we have: ||1. Augmenting the JCR Resource Provider - {{/jcr:id/}}||2. Creating a new Resource Provider for ID addressing||3. Extending the Resource API|| |Pros: * simple, low effort implementation * can be implemented behind a configuration toggle|Pros: * isolates providers and allows for separate configurations * since a provider has a mount path, the root for ID addressing is configurable|Pros: * brings the IDs as first class citizens to the Resource API * allows resource retrieval by ID or path without providing any special prefixes| |Cons: * adds a path prefix into the resource tree * might require setting explicit authentication configurations to not allow any HTTP browsing under {{/jcr:id}} for unauthenticated users|Cons: * adds a path prefix into the resource tree (via its mount path) * might require setting explicit authentication configurations to not allow any HTTP browsing under its root * duplicates functionality, since this would also be a JCR provider|Cons: * must ensure ID uniqueness across Resource Providers * difficult to implement since the Resource API has a large footprint| This shows clearly that 2 is not really a different option compared to 1. 3 is interesting, but I don't think we can solve the uniqueness requirement. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839511#comment-17839511 ] Radu Cotescu commented on SLING-12300: -- [~enorman], nobody trivialised your concerns. I’m not sure if everyone is familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}} property and I was just trying to explain the problem space. In addition, you expressed that there would be security issues by implementing this feature, but didn’t explain which. Predictability is not a security concern IMO if you correctly use ACLs. [~paul.bjorkstrand], for my use-case I only need those resources addressable by ID at the Java API level. The application that is built on top controls the URL space, but I wanted to use the Sling API for accessing the resource tree. You could ask why the contradiction: update the JCR resource provider to use a feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is just easier to use and simpler to understand for developers than the JCR one. Adding a new Resource Provider could also be an option, but in the end it would perform the same function in the same way: it would offer a way to retrieve resources by ID from its mount root, whichever that will be. I also thought about extending the Sling Resource API, but given that right now only one commonly use provider generates IDs for the resources it creates I thought it would be too complex and not provide so many gains. I will obviously not push something that the Sling community doesn’t agree with, but I would like that we discuss the alternatives and pick the solution that makes the most sense in terms of effort/benefits. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839473#comment-17839473 ] Carsten Ziegeler commented on SLING-12300: -- [~paul.bjorkstrand] Thanks for the detailed response. I think we have a slightly misleading discussion here, the current implementation is a *resource provider* - granted, that provider is not explicitly mounted at "/jcr:id", but there is no huge difference, except maybe that it would be possible to reconfigure the path to something else or disable the provider. I understand the ask for making an identifier a first class citizen in the Sling API, but I'm not sure that this would really change the picture that much. I rather think, the underlying question is whether we want to make resources addressable through their identifier via the http API or not. An identifier based resource API would allow that, the path based approach taken here does not allow it. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839459#comment-17839459 ] Joerg Hoh commented on SLING-12300: --- {quote}I think I would prefer that the uuid not be addressable so easily. That seems to be a security hole where someone could just do a brute force attack to try all the possible values and find paths that exist. {quote} I want to address the "security hole" by stating that also here the authorization setup of the underlying JCR repository applies. That means, also by this method user cannot access nodes for which they are not authorized. If you want to make nodes not available to the anonymous user, then don't provide the anonymous user read access to it. If your application has path-based restrictions to prevent direct access to certain paths (on top of the existing JCR restrictions), this approach using the UUID lookup has the ability to circumvent it and expose nodes which would be otherwise not accessible due to the path restrictions. By then it should be trivial to add another path-based restriction to prevent access to /jcr:id/ as well. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839419#comment-17839419 ] Paul Bjorkstrand commented on SLING-12300: -- I apologize if I am perceived as trivializing; I am trying to understand your concern, but I am not able to find any reason (other than security/privacy) why having the UUIDs addressable is a problem. I do want to understand what the concern about having some kind of predictability is, though. Based on part of your previous comments, I would like to address some of the concerns strictly related to predictability. bq. Basically, I'm not putting a server on the public internet with predictable addresses. I don't think that predictability is necessarily a problem in itself. In many situations (especially for things based on Sling), predictability is not a detriment but a feature. I know that there are Sling implementations that are not AEM, but using AEM as an example, you already have a large swath of partially predictable addresses. Public data primarily lives under {{/content}}. (Mostly private) user data lives under {{/home}}, (almost entirely private) application data/code lives under {{/apps}}. These root segments are entirely predictable. If you will oblige, I would like to run through an example comparing UUIDs vs. paths in terms of predictability, starting with some assumptions: # The "root path segments" in a given implementation are entirely predictable. # Paths consist of characters found in the following regex: {{[A-Za-z0-9-/]}}. This gives you 64 characters to choose from (more or fewer characters could be used, and these seem common enough in URLs). #* I chose this character set because it made the math easier, since 64 is a power of 2. #* More characters could be used, but it doesn't really change the math much. # Paths of nodes are entirely random, using the character set above. # Every node in a given Sling instance has {{mix:referenceable}} applied and is provisioned a UUID. # Paths could be any random combination of the characters from the regex above. In theory, a path could be of unlimited length, while UUIDs are finite, that is true. Using the assumptions above, for a path to be less predictable than a UUID, it would need to be at least than 21 characters long _beyond any predictable root(s)_. I won't go into the math too deeply, but the point where 64^x^ crosses 2^122^ is approximately 20.41. Anything 20 characters or less is more prone to brute force attacks than a UUID! _Note, even if you use all 8 bits of ASCII, you get 256^x^, which makes the length needed 16 characters (~15.25). In practice, paths are almost never random strings of characters. They have meaning in their names, often semantic and syntactic restrictions (depending on the creator's language). System rules can also reduce what paths are allowed (e.g., {{//}} is not legal because of the sequential slashes). Additionally, paths are usually relatively short. My experience tells me that paths are rarely more than 50 characters long in the public part of the application. Lastly, not every node in a given instance is going to have {{mix:referenceable}}, and thus not every node has a UUID that could be brute-forced. If your concern is not security or privacy related can help me understand what it is [~enorman]? > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839407#comment-17839407 ] Eric Norman commented on SLING-12300: - [~paul.bjorkstrand] It offends me that you and [~radu] continue to trivialize my concerns as "security by obscurity". That is not my argument and it never was, so please stop doing that. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839397#comment-17839397 ] Paul Bjorkstrand commented on SLING-12300: -- To clarify my position: I am not against having a mechanism to access them via identifier. My argument is mostly around the 'magic" path of {{/jcr:id/*}}. To me, I feel using a new method (as mentioned above) to perform this function. If you are creating an application that works outside the typical Sling hierarchical retrieve, it should probably be a new primitive in Sling, and not comingled with the existing {{getResource()}}. An argument for this functionality might be: Sling already have vanity paths that muddy this concept, so what is the concern for another? About the security argument, I think it is fair to say that we all know that "security by obscurity" is no security at all. Just because there is some means to access nodes by some ID that has a smaller universe of unique identifiers compared to the path does not change any of the security characteristics...unless you are using obscurity as your security mechanism. As Radu stated, the security checks performed are still the same ones that would be performed on the target node/resource, so there is no real security weakening here. While I still think that adding the magic path is still a possible source of confusion, I am not so against it after some deeper thinking on it. I still believe that a new method would be better, but it seems reasonable, especially when compared side-by-side with vanities. Would creating a new resource provider actually duplicate a lot? Or would you be able to build this as an additional provider in the same bundle as the JCR Resource Provider, and use the same functionality directly? > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839392#comment-17839392 ] Carsten Ziegeler commented on SLING-12300: -- I think we have two questions here: - do we want to have a mechanism that allows to get resources (JCR resources in this case) by identifier? - if the answer to the first question is yes, then how does it look like? I'm not sure if we agree to answer the first question with a yes based on the comments here, so lets get that one out of the way first. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839166#comment-17839166 ] Radu Cotescu commented on SLING-12300: -- In case you were to build an application that provided web resources identified by UUIDs, this would allow for efficient resource-by-id retrieval compared to what you'd have to do without this support at the Resource Provider level. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839155#comment-17839155 ] Eric Norman commented on SLING-12300: - [~radu] I know how long a UUID value is, how it is formatted and what characters are allowed in there. That is a much smaller universe then all the possible paths that may exist. I still having seen a good reason why this is needed. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839151#comment-17839151 ] Radu Cotescu commented on SLING-12300: -- {quote} I could get a match on the first try if I get lucky. Basically, I'm not putting a server on the public internet with predictable addresses. {quote} We're talking about UUIDs in this case, which are anything but predictable. Paths are definitely more predictable if we were to compare the two. But even so, the resources are either protected by ACLs or public, both making the security discussion moot. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839145#comment-17839145 ] Eric Norman commented on SLING-12300: - [~radu] the size of the number is irrelevant. I could get a match on the first try if I get lucky. Basically, I'm not putting a server on the public internet with predictable addresses. The resource path is the only address I need. I'm not sure this solution is necessary for general usage and you can make a private implementation for your use case if you really need it. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839137#comment-17839137 ] Radu Cotescu commented on SLING-12300: -- {quote}That seems to be a security hole where someone could just do a brute force attack to try all the possible values and find paths that exist. {quote} They'd only have to try 2{^}122{^} combinations. In all seriousness now, the same ACLs apply. I don't see how the addressing mode introduces a security hole. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839135#comment-17839135 ] Eric Norman commented on SLING-12300: - I think I would prefer that the uuid not be addressable so easily. That seems to be a security hole where someone could just do a brute force attack to try all the possible values and find paths that exist. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839133#comment-17839133 ] Radu Cotescu commented on SLING-12300: -- {quote} If I were to add in something that provides resources under the path {{/jcr:id/*}}, it almost seems like it should be from a provider that services that path. {quote} Don't forget that the JCR provider is mounted on {{/}}. So technically {{/jcr:id}} in this case is a resource provided by this provider. If you were to reconfigure the provider on let's say {{/oak}}, then the "magic" path for identifier based retrieval would be {{/oak/jcr:id/}}. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839129#comment-17839129 ] Radu Cotescu commented on SLING-12300: -- [~joerghoh], how can your two asserts be true at the same time for a referenceable node?! A JCR node's identifier is its path or, if it has the {{mix:referenceable}} applied, its {{jcr:uuid}} property, like mentioned in the issue's description. In the PR I have provided some tests that show the path behaviour, namely the path will always be the node's path, regardless of how the resource was retrieved. While writing a new Resource Provider might provide better isolation, it would duplicate everything the JCR Provider does right now and it wouldn't provide much value compared to the current solution. Accessing a resource like {{http://localhost:8080/jcr:id/.json}} will be identical to {{http://localhost:8080/.json}}. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839116#comment-17839116 ] Paul Bjorkstrand commented on SLING-12300: -- I'm leaning towards [~joerghoh]'s opinion as well. To me, this seems better served by a new method like {{ResourceResolver#getResoureById(String jcrId);}} Having this functionality in {{getResource(..)}} method seems to be a possible source for confusion. If I were to add in something that provides resources under the path {{/jcr:id/*}}, it almost seems like it should be from a provider that services that path. That may also bring into it more problems, because I don't know if it is semantically correct for a resource provider under a given path to provide resources for another path. Is there a reason why this can't be a new method? > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[ https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839067#comment-17839067 ] Joerg Hoh commented on SLING-12300: --- I am not that happy with this magic string: * It does not feel sling-ish (I would expect a ResourceProvider for it) * I might break code, which relies on {noformat} String jcrIdPath="/jcr:id/12345678"; Resoure r = resourceResolver.getResource(jcrIdPath); assertEquals(fullPath,r.getPath()); {noformat} (although such code might break in other cases already today, when using aliases and vanity paths) * is it possible to do a request to http://localhost:8080/jcr:id/.html and get the result rendered? Do we want this to happen? * Right now it's not possible to turn off this behavior. > Provide a way to retrieve a JCR backed resource by its node identifier > -- > > Key: SLING-12300 > URL: https://issues.apache.org/jira/browse/SLING-12300 > Project: Sling > Issue Type: New Feature > Components: JCR >Reporter: Radu Cotescu >Assignee: Radu Cotescu >Priority: Major > Fix For: JCR Resource 3.3.0 > > > Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would > be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}} > property for referenceable nodes or the path. In systems that would like to > use UUID addressing, this would reduce the need for executing JCR queries for > resource retrieval and would avoid double-reads via the JCR and then Sling > API to obtain the resource. > In order to provide a unified behaviour, paths starting with the {{/jcr:id/}} > prefix should use the resource retrieval by node identifier. > [0] - > https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier() -- This message was sent by Atlassian Jira (v8.20.10#820010)