> From: Gary L Peskin [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, May 27, 2001 6:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: javax.xml.transform: prohibiting Java extensions
>
>
> Hi Julian --
Gary,
thanks for taking the time to answer my questions.
> According to Joe Kesselman
> (http://marc.theaimsgroup.com/?l=xalan-dev&m=97024906624126&w=2), the
> W3C has ruled that all namespace names should be absolute. While RFC
> 2396 does allow the scheme to define the absolute and relative URI
> syntax of the scheme-specific-part within that scheme, the "generic URI"
> syntax begins with "//" so we did the same to further emphasize visually
> that this is an absolute URI. At this stage, we're still kind of
> experimenting with the xalan: scheme so nothing is set in stone.
I think this is a misunderstanding. From RFC2396, chapter 3:
"An absolute URI contains the name of the scheme being used (<scheme>)
followed by a colon (":") and then a string (the <scheme-specific-part>)
whose interpretation depends on the scheme."
and from 3.1:
"Relative URI references are distinguished from absolute URI in that they do
not begin with a scheme name. Instead, the scheme is inherited from the
base URI, as described in Section 5.2."
So the very presence of a scheme name makes "xalan:..." absolute...
> As far as registering xalan:, we're still experimenting with this and
> awaiting XSLT 2.0 so I think that might be premature.
>
> Anyway, that was my thinking and if you have suggestions, please feel
> free.
>
> To eliminate the execution of extension functions in your application,
> please bear in mind that xalan:// syntax, while recommended, is not
> currently enforced and extension functions can be called even with a
> relative URI syntax (ie without the scheme).
Sure. This is why I think that to to achive security, the problem needs to
be approached differently.
> All extension function calls go through
> org.apache.xalan.extensions.ExtensionsTable.extFunction(...). This is a
> public method. You could subclass ExtensionsTable and override this
> method to prohibit extension function calls while in your code. Then,
> call org.apache.xpath.XPathContext.setExtensionsTable(..) to substitute
> your ExtensionsTable subclass for the actual ExtensionsTable class.
>
> You can get the current XPathContext from the current TransformerImpl by
> calling the getXPathContext() method of that TransformerImpl. So, you
> might try something like:
>
> myTransformer.getXPathContext().setExtensionsTable(myExtensionsTable);
>
> before you start your transform. Obviously, if you're not using the
> Transformer but creating your own XPathContext, you already have access
> to it!
>
> If you decide to take this path, I just noticed that the
> setExtensionsTable() method seems to have default (package) access
> instead of public. Why not try to change this to public and see if this
> method works for you, if it is appropriate. If so, please submit a
> bugzilla item and I will change the access on the setExtensionsTable()
> method to public.
Again, thanks for the feedback. I'll give this a try.
