Santuario
  1. Santuario
  2. SANTUARIO-79

Setting a URIResolver for the XSLT Transform

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Java
    • Security Level: Public (Public issues, viewable by everyone)
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      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

        Activity

        Hide
        sean.mullan added a comment -

        (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

        Show
        sean.mullan added a comment - (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
        Hide
        patrick peck added a comment -

        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

        Show
        patrick peck added a comment - 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
        Hide
        sean.mullan added a comment -

        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?

        Show
        sean.mullan added a comment - 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?

          People

          • Assignee:
            Unassigned
            Reporter:
            patrick peck
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development