[jira] [Commented] (SLING-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256724#comment-13256724 ] Alexander Klimetschek commented on SLING-2425: -- I had a quick look at the code. Generally it looks good wrt to the backwards compatibility and unit tests present. Only the case if the name is a path looks fragile with the custom parsing. For sure it does not catch relative path steps such as . or .., they will get escaped incorrectly. Looking at that I think that not doing any encodings in the value map layer is much simpler - this encoding logic can get endlessly complex and I guess there will always be a case where it fails if the application cannot decide what to do (e.g. escape / or not). Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler Fix For: JCR Resource 2.1.0 The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229309#comment-13229309 ] Alexander Klimetschek commented on SLING-2425: -- Sorry if my original description was unclear. The issue I have is that I can't read certain properties via the ValueMap, that can be created using the JCR API and the Sling POST servlet: 1. create properties: curl -u admin:admin -F -prop=value -F 1prop=value http://localhost:8080/tmp 2. try to read them: ValueMap map = resolver.getResource(/tmp).adaptTo(ValueMap.class); map.get(-prop, String.class); // fails map.get(1prop, String.class); // fails My current workaround (due to the fact that the encoding is not done in the cached variant): // right after fetching the map map.size(); // triggers readFully() internally map.get(1prop, String.class); // returns value Property names starting with - or numbers are affected (and more). (Agree this is a rare case, but in our use case we need to resort to a specific naming to separate these properties from others. And these are perfectly valid in JCR.) Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228277#comment-13228277 ] Alexander Klimetschek commented on SLING-2425: -- But mixing the Resource/ValueMap and JCR APIs is normal with Sling, especially considering the Sling POST servlet, which uses JCR directly and does not adhere to these escaping rules. Also, there is no limitation in JCR which this escaping fixes - as mentioned, this is the wrong escaping if any, as it reduces the allowed charset! ISO9075 is for xml (xpath queries), but not fir JCR paths. Furthermore the escaping is not documented in the API at all. What was the exact problem that lead to this? Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228532#comment-13228532 ] Alexander Klimetschek commented on SLING-2425: -- I see the point that we use the wrong escaping - however from an app perspective it doesn't matter. It's ugly if you access the content in a different way. It's impossible to access properties (or child node properties) that contain chars escaped by ISO9075, for example some-property. This is the major issue - my current workaround is to force the readFully() variant, in which it works because of the inconsistency. IMHO fixing this escaping is more important than backwards compatibility. Code relying on that (undocumented feature) would need to be adapted, using the ISO9075 encoding themselves before accessing ValueMap. Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227686#comment-13227686 ] Alexander Klimetschek commented on SLING-2425: -- How do you think the inconsistency can be resolved when using the JCR API as well? Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek Assignee: Carsten Ziegeler The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212744#comment-13212744 ] Alexander Klimetschek commented on SLING-2425: -- BTW, this made me crazy while debugging: looking up an existing -foo property failed in my case, but when I stepped through the code, it worked. It turned out that since the ValueMap is a Map, it is specifically handled in my IDE's debugging inspector and it calls at least size() automatically - which triggers a readFully(), while the normal code path just yields an individual read() call. Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2425) Incorrect and inconsistent escaping of property names used in JcrPropertyMap
[ https://issues.apache.org/jira/browse/SLING-2425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13212791#comment-13212791 ] Alexander Klimetschek commented on SLING-2425: -- The ISO9075 encoding was introduced with SLING-1077. Incorrect and inconsistent escaping of property names used in JcrPropertyMap Key: SLING-2425 URL: https://issues.apache.org/jira/browse/SLING-2425 Project: Sling Issue Type: Bug Components: JCR Affects Versions: JCR Resource 2.0.10 Reporter: Alexander Klimetschek The JcrPropertyMap uses the (wrong) ISO9075 encoding for property names, and this also behaves differently between the read() and readFully() variants. 1) ISO9075 is needed for XML names, e.g. for mapping JCR names into Xpath queries. But the set of valid JCR names is much larger (for example - is valid, while it is not allowed in ISO9075 and becomes _x002d_). org.apache.jackrabbit.util.Text#escapeIllegalJcrChars() must be used instead to escape any string for use as JCR names. [0] 2) Inconsistency: a) read() will take the key and use ISO9075#encodePath(), before looking up the jcr property using the encoded variant b) readFully() will go through all jcr properties and cache them with the key using ISO9075#decode() Hence for all valid JCR names, which are not valid under ISO9075 (like 1_prop, -foo), these can be looked up using the cached variant b) (as decode() won't touch them), while they cannot be looked up using read() at all due to the forced arbitrary escaping. I think there should be no auto-magically escaping at all (also not in the accompanying JcrModifiablePropertyMap). Incorrect naming errors should simply be passed through, it is the job of the application to handle that. The framework should not run an arbitrary undocumented escaping, if it cannot enforce that anyway, since there are other ways to create properties with a different valid char set (using the JCR API). [0] http://wiki.apache.org/jackrabbit/EncodingAndEscaping -- 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-2136) Sling POST Servlet: Configuration of Allowed Paths
[ https://issues.apache.org/jira/browse/SLING-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13209308#comment-13209308 ] Alexander Klimetschek commented on SLING-2136: -- Ok, I missed the existing http://svn.apache.org/viewvc/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/servlets/PathsServlet.java?view=markup registered under /testing/PathsServlet/foo. Weird that this does not conflict... Sling POST Servlet: Configuration of Allowed Paths -- Key: SLING-2136 URL: https://issues.apache.org/jira/browse/SLING-2136 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Andrew Khoury Attachments: post_servlet_filter-1205238.patch It would be nice if you could configure rules or regular expressions for paths the sling post servlet is allowed to work under. This would be good for both security reasons and for protecting against conflicts with other servlets. For example: Let's say you have a servlet ReplicationServlet registered to receive POST requests under path /bin/replicate. However, during startup, before the ReplicationServlet component has been enabled, a user tries to do a POST to /bin/replicate. In this case, instead of executing the ReplicationServlet, the POST servlet is executed and it creates a node under /bin/replicate. Now, as long as the node /bin/replicate exists... the ReplicationServlet will not be executed for requests to /bin/replicate. This presents a problem and explains the necessity for this feature. -- 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-2136) Sling POST Servlet: Configuration of Allowed Paths
[ https://issues.apache.org/jira/browse/SLING-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13208596#comment-13208596 ] Alexander Klimetschek commented on SLING-2136: -- @Justin: The paths are different in your integration test, explaining why they don't conflict: - servlet registered under /testing/PathsServletNodeServlet - content path created at /testing/PathsServlet/foo The content path should be exactly the same (/testing/PathsServletNodeServlet) to test the original described issue. I am quite sure that this is a problem. Sling POST Servlet: Configuration of Allowed Paths -- Key: SLING-2136 URL: https://issues.apache.org/jira/browse/SLING-2136 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Andrew Khoury Attachments: post_servlet_filter-1205238.patch It would be nice if you could configure rules or regular expressions for paths the sling post servlet is allowed to work under. This would be good for both security reasons and for protecting against conflicts with other servlets. For example: Let's say you have a servlet ReplicationServlet registered to receive POST requests under path /bin/replicate. However, during startup, before the ReplicationServlet component has been enabled, a user tries to do a POST to /bin/replicate. In this case, instead of executing the ReplicationServlet, the POST servlet is executed and it creates a node under /bin/replicate. Now, as long as the node /bin/replicate exists... the ReplicationServlet will not be executed for requests to /bin/replicate. This presents a problem and explains the necessity for this feature. -- 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-2364) ResourceUtil should provide a method to get the parent on an arbitrary level
[ https://issues.apache.org/jira/browse/SLING-2364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206904#comment-13206904 ] Alexander Klimetschek commented on SLING-2364: -- FWIW: The org.apache.jackrabbit.Text helper in jackrabbit-jcr-commons already provides getRelativeParent() (and one to ignore trailing slashes) and getAbsoluteParent(). http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/util/Text.html ResourceUtil should provide a method to get the parent on an arbitrary level Key: SLING-2364 URL: https://issues.apache.org/jira/browse/SLING-2364 Project: Sling Issue Type: Improvement Components: API Affects Versions: API 2.2.2 Reporter: Konrad Windszus Attachments: getParent.patch Please provide the method String getAbsoluteParent(String path, int level) to return the parent path on the given level. -- 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-2251) RedirectServlet should create relative Location headers as often as possible
[ https://issues.apache.org/jira/browse/SLING-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168499#comment-13168499 ] Alexander Klimetschek commented on SLING-2251: -- @Antonio: It's already committed :-) Could someone fix the integration tests (Troy provided a patch already) and resolve + close this bug? Thanks! RedirectServlet should create relative Location headers as often as possible Key: SLING-2251 URL: https://issues.apache.org/jira/browse/SLING-2251 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Get 2.1.2 Reporter: Alexander Klimetschek Attachments: SLING-2251-VanityPathTest.patch, SLING-2251.patch SLING-1965 (more specifically http://svn.apache.org/viewvc?view=revisionrevision=903175 ) changed the redirect servlet so that it _always_ generates an absolute location header. The issue does not give much reasoning for that. The problem is that this breaks cases where a Sling server is run behind a proxy (which does not or cannot rewrite the Location header), as the redirect (http://localhost:8080/some/path;) might not match the externally visible domain (e.g. https://my.domain.com;). Also, the schema is fixed (e.g. might switch external https back to http). A solution would be to generate absolute URLs only if a resource resolver mapping (/etc/map) includes an explicit domain and thus generates an absolute URL. For all other cases, relative URLs should be generated. AFAICS, this was the case before SLING-1965. -- 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-2251) RedirectServlet should create relative Location headers as often as possible
[
https://issues.apache.org/jira/browse/SLING-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164249#comment-13164249
]
Alexander Klimetschek commented on SLING-2251:
--
Probably not important, but the change in the test case made the isAbsolute
case wrong: it does the same relative check as the else clause.
-private static void assertEqualsUri(String expected, String actual) {
-assertEquals(TEST_PREFIX + expected, actual);
+private static void assertEqualsUri(String expected, String actual,
boolean isAbsolute) {
+if (isAbsolute) {
+assertEquals(expected, actual);
+} else {
+assertEquals(expected, actual);
+}
}
RedirectServlet should create relative Location headers as often as possible
Key: SLING-2251
URL: https://issues.apache.org/jira/browse/SLING-2251
Project: Sling
Issue Type: Improvement
Components: Servlets
Affects Versions: Servlets Get 2.1.2
Reporter: Alexander Klimetschek
Attachments: SLING-2251.patch
SLING-1965 (more specifically
http://svn.apache.org/viewvc?view=revisionrevision=903175 ) changed the
redirect servlet so that it _always_ generates an absolute location header.
The issue does not give much reasoning for that.
The problem is that this breaks cases where a Sling server is run behind a
proxy (which does not or cannot rewrite the Location header), as the redirect
(http://localhost:8080/some/path;) might not match the externally visible
domain (e.g. https://my.domain.com;). Also, the schema is fixed (e.g. might
switch external https back to http).
A solution would be to generate absolute URLs only if a resource resolver
mapping (/etc/map) includes an explicit domain and thus generates an absolute
URL. For all other cases, relative URLs should be generated. AFAICS, this was
the case before SLING-1965.
--
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-2136) Sling POST Servlet: Configuration of Allowed Paths
[ https://issues.apache.org/jira/browse/SLING-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156808#comment-13156808 ] Alexander Klimetschek commented on SLING-2136: -- Forcing the :operation parameter is not very elegant IMHO and it is not backwards compatible (all existing forms would have to be changed). Also, the problem mostly exists for non-existing paths (such as virtual servlet paths), because after they get created accidentally through the post servlet, the virtual resolution is immediately eliminated. For cases where a node is present, but only the actual servlet currently not available, you usually don't overwrite the resource type. Hence the next call when the servlet is present again will work. Only the properties have been written. And if such a servlet acts as a filter for the sling post servlet (and will forward to it afterwards, a quite common case), forcing the :operation parameter won't help, as it will be there anyway. I think the filtering is a simple solution at least for the virtual paths. One doesn't have to use it. Sling POST Servlet: Configuration of Allowed Paths -- Key: SLING-2136 URL: https://issues.apache.org/jira/browse/SLING-2136 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Post 2.1.2 Reporter: Andrew Khoury Attachments: post_servlet_filter-1205238.patch It would be nice if you could configure rules or regular expressions for paths the sling post servlet is allowed to work under. This would be good for both security reasons and for protecting against conflicts with other servlets. For example: Let's say you have a servlet ReplicationServlet registered to receive POST requests under path /bin/replicate. However, during startup, before the ReplicationServlet component has been enabled, a user tries to do a POST to /bin/replicate. In this case, instead of executing the ReplicationServlet, the POST servlet is executed and it creates a node under /bin/replicate. Now, as long as the node /bin/replicate exists... the ReplicationServlet will not be executed for requests to /bin/replicate. This presents a problem and explains the necessity for this feature. -- 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-2251) RedirectServlet should create relative Location headers as often as possible
[ https://issues.apache.org/jira/browse/SLING-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13130579#comment-13130579 ] Alexander Klimetschek commented on SLING-2251: -- An (untested) patch would be - at the end of toRedirect(), lines 230-237 - simply return the result of the mapping: return request.getResourceResolver().map(request, target.toString()); AFAIK, the resource resolver's map method (with request object) already does the necessary logic to create a relative path if the request domain matches the mapping domain, and an absolute path if it differs. RedirectServlet should create relative Location headers as often as possible Key: SLING-2251 URL: https://issues.apache.org/jira/browse/SLING-2251 Project: Sling Issue Type: Improvement Components: Servlets Affects Versions: Servlets Get 2.1.2 Reporter: Alexander Klimetschek SLING-1965 (more specifically http://svn.apache.org/viewvc?view=revisionrevision=903175 ) changed the redirect servlet so that it _always_ generates an absolute location header. The issue does not give much reasoning for that. The problem is that this breaks cases where a Sling server is run behind a proxy (which does not or cannot rewrite the Location header), as the redirect (http://localhost:8080/some/path;) might not match the externally visible domain (e.g. https://my.domain.com;). Also, the schema is fixed (e.g. might switch external https back to http). A solution would be to generate absolute URLs only if a resource resolver mapping (/etc/map) includes an explicit domain and thus generates an absolute URL. For all other cases, relative URLs should be generated. AFAICS, this was the case before SLING-1965. -- 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
