[jira] [Commented] (SLING-2457) ResourceUtil.isA() fails if resource has a type, whose super type is not readable
[ https://issues.apache.org/jira/browse/SLING-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254061#comment-13254061 ] Jeff Young commented on SLING-2457: --- Is the fail-over from Resource.isResourceType to isAInternal really buying us anything? Why not just modify the existing isA to use isResourceType? (I presume it has something to do with AbstractResource, since your proposal short-circuits the isResourceType call there, but I'm not able to connect the dots.) ResourceUtil.isA() fails if resource has a type, whose super type is not readable - Key: SLING-2457 URL: https://issues.apache.org/jira/browse/SLING-2457 Project: Sling Issue Type: Bug Components: API Affects Versions: API 2.2.0 Reporter: Tyson Norris * define a resource at /content/component/foo whose type is myapp/components/bar * define bar at /apps/myapp/components/bar * on /apps/myapp/components/bar, set sling:resourceSuperType as /libs/components/bar2 If resolver from resource.getResourceResolver() cannot access /libs/components/bar2, then ResouceUtil.isA(resource, components/bar2) returns false, otherwise it returns true. There could be an argument that it should not return true in any case, however, if you set resourceSuperType on resource as components/bar2, then it returns true with current implementation. At least one of these is wrong, I think. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2441) AuthenticationInfo.put() throws if method is null
[ https://issues.apache.org/jira/browse/SLING-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240489#comment-13240489 ] Jeff Young commented on SLING-2441: --- If we stick with the old behaviour than someone will need to fix AuthenticationInfoPostProcessorBridge. AuthenticationInfo.put() throws if method is null - Key: SLING-2441 URL: https://issues.apache.org/jira/browse/SLING-2441 Project: Sling Issue Type: Bug Components: Authentication Affects Versions: Auth Core 1.0.6 Reporter: Jeff Young Assignee: Justin Edelson Labels: newbie, patch Fix For: Auth Core 1.1.0 Attachments: auth_info_put.patch Historically the AUTH_TYPE of an AuthenitcationInfo had to be defined (ie: non-null), but we're now using it for anonymous access as well, with a null AUTH_TYPE. The put() method, however, throws if passed a null AUTH_TYPE. (This is triggered, for instance, by CQ's AuthenticationInfoPostProcessorBridge, which does a putAll().) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2446) JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
[
https://issues.apache.org/jira/browse/SLING-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236621#comment-13236621
]
Jeff Young commented on SLING-2446:
---
Hi Justin,
Just to note that I'm working on a patch; should be uploaded in a few hours.
Cheers,
Jeff.
JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
--
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: Bug
Components: JCR
Reporter: Jeff Young
Assignee: Justin Edelson
Labels: newbie, patch
Fix For: JCR Resource 2.1.0
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2446) Add support for BigDecimal JCR values
[
https://issues.apache.org/jira/browse/SLING-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236664#comment-13236664
]
Jeff Young commented on SLING-2446:
---
Most of my changes were the same as Justin's, so I just pulled his in. My
tests were slightly more complete, however, so I've uploaded a patch containing
just my extra tests.
Add support for BigDecimal JCR values
-
Key: SLING-2446
URL: https://issues.apache.org/jira/browse/SLING-2446
Project: Sling
Issue Type: New Feature
Components: JCR
Reporter: Jeff Young
Assignee: Justin Edelson
Labels: newbie, patch
Fix For: JCR Resource 2.1.0
Attachments: BigDecimal_tests_.patch
JCR supports the typehint {Decimal} for java.math.BigDecimal, but
JcrPropertyMap doesn't know about it so doing a map.get(propName,
BigDecimal.class) returns null.
Likewise, you should be able to adapt a Property Resource into a BigDecimal.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13197723#comment-13197723 ] Jeff Young commented on SLING-2320: --- My last patch (which contains all the good bug fixes; see a - d above) still needs committing. Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13190968#comment-13190968 ] Jeff Young commented on SLING-2236: --- Imagine our poor developer trying to debug this. A workaround isn't very useful if there's no indication that they ought to use the workaround. It's not the operation lookup that's the issue: it's that (conceptually) the WRONG servlet is processing the operation (because we couldn't read the sling:resourceType to get the RIGHT servlet). We at least give our developer a hint with a 404; they're going to be pretty baffled when we report an invalid operation. Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1319#comment-1319 ] Jeff Young commented on SLING-2236: --- OK, one more attempt (and then I promise to shut up): Let's say the :operation -is- one the default servlet knows. In that case, it's going to report a 404. So, conceptually, in the bad operation case the default servlet sees two problems: we can't read the resource and we don't know what the operation is. There's nothing in the Sling contract which states that operation errors have precedence over read-access errors. (And, while this particular instance doesn't appear to have any exploitability, it would seem that in general you'd want to give read-access errors precedence in order to reduce the possibility of leaking resource exists information.) Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2236) Default POST servlet reports invalid operation when it should report 404
[ https://issues.apache.org/jira/browse/SLING-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191227#comment-13191227 ] Jeff Young commented on SLING-2236: --- Hi Justin, In my first example, if I use a -known- operation on a non-readable resource, then the servlet -will- return a 404. It's true that different operations may have different -specific- access requirements. But they should only handle those -after- checking for basic read access. To do anything else risks information leakage. So, yes, I like your precondition idea, but there's only one, and it's invariant: do we at least have read-access? If not, return a 404. Don't give the caller -any- other information. Default POST servlet reports invalid operation when it should report 404 Key: SLING-2236 URL: https://issues.apache.org/jira/browse/SLING-2236 Project: Sling Issue Type: Bug Components: Servlets Reporter: Jeff Young Priority: Minor In sling/servlets/post/impl/SlingPostServlet.java's doPost() method, we look up the operation (and report an unknown operation) before checking privileges. I'd like to propose that when the operation is not understood, we first check for read access to the resource, and if unsuccessful, report that instead of reporting invalid operation. Here's the issue: say I define my own POST servlet which supports :operation=foo. I set a sling:resourceType so that my POST servlet gets invoked. All fine and good. Now someone without read access to the resource tries to do an :operation=foo. Sling can't read the sling:resourceType (no read access), and so invokes the default POST servlet instead of my custom POST servlet. It looks up :operation=foo and reports invalid operation (which is pretty misleading). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2353) Prevent sling:include resource=%= null % / to include itself
[ https://issues.apache.org/jira/browse/SLING-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13186296#comment-13186296 ] Jeff Young commented on SLING-2353: --- sling:include with a null resource (whether specified as null or defaulted to null) doesn't appear to have any value other than backwards compatibility. It's certainly not an elegant way to include self, nor does it appear to be the only way. Being able to include self (with other selectors/extensions) certainly does have value, but as stated, we don't need include null to accomplish that. So, if we need backward compatibility, then I'd favour WONTFIX. Otherwise, I'd favour throwing an IllegalArgumentException. Prevent sling:include resource=%= null % / to include itself -- Key: SLING-2353 URL: https://issues.apache.org/jira/browse/SLING-2353 Project: Sling Issue Type: Bug Components: Scripting Affects Versions: Scripting JSP-Taglib 2.1.2 Reporter: Tobias Bocanegra Assignee: Carsten Ziegeler Priority: Minor Fix For: Scripting JSP-Taglib 2.1.4 If you add this sling:include to a JSP sling:include resource=%= null % / then it will cause the page to keep including itself recursively making the server slow. there is a recursion limitation though to prevent endless loops. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13167650#comment-13167650 ] Jeff Young commented on SLING-2320: --- BTW: final installment is json_get_servlet_rewrite.patch. Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Justin Edelson Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff, json_get_servlet_rewrite.patch, servlet_tests.patch Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163970#comment-13163970 ] Jeff Young commented on SLING-2320: --- Felix, your change to the logic turns off the DOS limitation for infinity as well (which is encoded as -1). The second half of the if stmt should be != 1, not 1. I've just finished writing a unit test for the servlet, so I'll go ahead and fix this as well in the patch. I'm planning to upload two separate patches: first the unit test (with this fix in it), and then a cleanup of the exception behaviour. Sound good? Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Fix For: Servlets Get 2.1.4 Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13162978#comment-13162978 ] Jeff Young commented on SLING-2320: --- Note: the patch has SLING- in it because I thought I had to create it before creating the JIRA issue. (And then, of course, I forgot to update it before uploading.) Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
[ https://issues.apache.org/jira/browse/SLING-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13163073#comment-13163073 ] Jeff Young commented on SLING-2320: --- Yeah, I was also somewhat concerned by the fact that ResourceTraversor.getParentJSONObject() will throw two exceptions *for every node traversed*. (The first is thrown because the leading / isn't trimmed off of pathDiff, yielding an empty path segment, and the second because the last path looked for is self, which of course doesn't exist yet. But I didn't want to extend my remit beyond what I had been granted permission to fix Current DOS-prevention for infinity.json can prevent enumeration of children Key: SLING-2320 URL: https://issues.apache.org/jira/browse/SLING-2320 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Get 2.1.0 Reporter: Jeff Young Assignee: Felix Meschberger Labels: newbie, patch Attachments: jsonRenderer.diff Original Estimate: 1h Remaining Estimate: 1h A request of resource.1.json should always succeed, as it's the primary method for JSON introspection of the repository hierarchy. DOS protection should only apply to deep traversals; that is, anything with a depth greater than 1 (and, in particular, resource.infinity.json). For a fuller discussion, see: http://www.mail-archive.com/dev@sling.apache.org/msg13961.html. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
