[jira] [Created] (SLING-2446) JCR-1609 added DecimalType, but it didn't get in to Sling's JcrPropertyMap
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
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] [Created] (SLING-2441) AuthenticationInfo.put() throws if method is null
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 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] [Created] (SLING-2320) Current DOS-prevention for infinity.json can prevent enumeration of children
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 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). -- 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] [Created] (SLING-2236) Default POST servlet reports invalid operation when it should report 404
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 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
