You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by bu...@apache.org on 2006/04/19 13:54:08 UTC
DO NOT REPLY [Bug 39349] New: - Setting a URIResolver for the XSLT Transform
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39349>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39349
Summary: Setting a URIResolver for the XSLT Transform
Product: Security
Version: cvs
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Signature
AssignedTo: security-dev@xml.apache.org
ReportedBy: patrick@zync.at
Hello,
I apologize, if this functionality is already implemented and I just fail
to see it.
Using the JSR 105 API I see no way to set a javax.xml.transform.URIResolver for
resolving URIs when performing an XSLT Transform. This means, that the default
URIResolver will be used, which is not always desirable.
Looking at the source code, I can see 2 ways of implementing this
(I assume you do not want to change the API of XMLCryptoContext):
1) explicitly setting a URIResolver property in the XMLCryptoContext,
e.g. XMLCryptoContext.setProperty("javax.xml.transform.URIResolver", myURIResolver)
2) implementing a URIResolver that internally uses the URIDereferencer
from the XMLCryptoContext
In both cases, the resulting URIResolver would have to be passed down to the
org.apache.xml.security.transforms.implementations.TransformXSLT that
actually does the transform.
If you indicate which way you would prefer it, i would be willing to implement
this functionality and provide a patch.
Regards,
Patrick Peck
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39349] - Setting a URIResolver for the XSLT Transform
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39349>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39349
------- Additional Comments From sean.mullan@sun.com 2006-04-19 15:30 -------
(In reply to comment #0)
> Hello,
>
> I apologize, if this functionality is already implemented and I just fail
> to see it.
>
> Using the JSR 105 API I see no way to set a javax.xml.transform.URIResolver for
> resolving URIs when performing an XSLT Transform. This means, that the default
> URIResolver will be used, which is not always desirable.
>
> Looking at the source code, I can see 2 ways of implementing this
> (I assume you do not want to change the API of XMLCryptoContext):
>
> 1) explicitly setting a URIResolver property in the XMLCryptoContext,
> e.g. XMLCryptoContext.setProperty("javax.xml.transform.URIResolver",
myURIResolver)
>
> 2) implementing a URIResolver that internally uses the URIDereferencer
> from the XMLCryptoContext
>
> In both cases, the resulting URIResolver would have to be passed down to the
> org.apache.xml.security.transforms.implementations.TransformXSLT that
> actually does the transform.
>
> If you indicate which way you would prefer it, i would be willing to implement
> this functionality and provide a patch.
Solution 1 is technically an API change (since you propose defining a
property starting with "javax"), so it would need to go through the Java
Community Process and a maintenance revision of the specification would need
to be released. Since we have only just recently finalized JSR 105 and don't
have any immediate plans for a maintenance revision, this
option would take a while. Alternatively, you could define an
implementation-specific property starting with org.apache (but it would
be specific to the Apache implementation).
Solution 2 is probably better. However, I should note for a tighter JSR
105 integration, the Apache Transform implementations should be
changed to extend the JSR 105 javax.xml.crypto.dsig.TransformService class.
Then the XMLCryptoContext would be passed to the
transform method (inherited from TransformService) of the TransformXSLT
impl, and from there you could get
the URIDereferencer from the XMLCryptoContext. But that may be more of
a long-term (XMLSec 2.0?) change since it would require some fairly significant
restructuring/modification of the classes.
--Sean
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39349] - Setting a URIResolver for the XSLT Transform
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39349>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39349
------- Additional Comments From patrick@zync.at 2006-04-25 09:04 -------
Sean,
Thank you for your informative reply. I understand, why (1) is not an option
at the moment. But from looking at the code, maybe you could reconsider (2).
I think there is a solution that does not require the kind of class
restructuring that you suggest.
Currently, the org.jcp.xml.dsig.internal.dom.ApacheTransform class acts as
the glue between the JSR105 and the Apache implementation. In the 'transformIt'
method of this class, the respective Apache Transform is instantiated. It
is in this method, where both the XMLCryptoContext and the Apache Transform
Impl would be available at the same time. There it would be possible to set
a URIResolver (that is a wrapper over the URIDereferencer of the
XMLCryptoContext) to the Apache Transform object - provided such a setter is
added to the class, which shouldn't be a problem because it doesn't break
compatibility. In the Apache TransformXSLT 'enginePerformTransform' method
the URIResolver would be accessible via _transformObject.getURIResolver().
What do you think about that?
regards,
Patrick
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
DO NOT REPLY [Bug 39349] - Setting a URIResolver for the XSLT Transform
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39349>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39349
------- Additional Comments From sean.mullan@sun.com 2006-05-09 20:16 -------
Hi Patrick,
Sorry for not getting back to you earlier. I think your proposed solution is
fine. Can you attach a patch (or code diffs) to this bug when you have it
ready?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.