升级到java7u25后,XML dig sig错误 [英] XML dig sig error after upgrade to java7u25

查看:110
本文介绍了升级到java7u25后,XML dig sig错误的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个用于签署XML文档的Java应用程序。将Java升级到最新版本(Java7u25)后,它将停止工作。我收到以下错误:

I have a Java application for signing XML documents. After upgrading Java to the latest version (Java7u25) it stops working. I get the following error:

javax.xml.crypto.dsig.XMLSignatureException:
javax.xml.crypto.URIReferenceException: 
com.sun.org.apache.xml.internal.security.utils.resolver.ResourceResolverException:
Cannot resolve element with ID ...

恢复到java7u21解决了这个问题。 XML Dig Sig API中是否有任何更改导致此错误?

Reverting back to java7u21 solves the problem. Is there any change in the XML Dig Sig API that causes this error?

推荐答案

此处存在同样的问题。由于演变,似乎是JVM内部的一个错误。

Same problem here. Seems to be a bug inside the JVM due to an evolution.

我已将其转移到 com.sun.org.apache.xml .internal.security.utils.resolver.implementations.ResolverFragment

在java 7u21&之前:

In java 7u21 & before :

91: // Element selectedElem = doc.getElementById(id);
92: selectedElem = IdResolver.getElementById(doc, id);

在java 7u25中:

In java 7u25 :

87: selectedElem = doc.getElementById(id);
    //...
93: if (secureValidation) {

secureValidation 是指关于XML Sig验证的java 7u25进化(参见 changelog )因此他们必须在进行此演变时 更改其他内容

secureValidation refers to java 7u25 evolution on XML Sig validation (see changelog) so they must have broken changed something else while working on this evolution.

我们通过向 javax.xml.crypto.URIDereferencer 来解决此问题> javax.xml.crypto.dom.DOMCryptoContext.setURIDereferencer(URIDereferencer)它能够解析尚未存在于DOM文档树中的节点(XMLObject中的片段)。

We've worked around this issue by providing a custom javax.xml.crypto.URIDereferencer to javax.xml.crypto.dom.DOMCryptoContext.setURIDereferencer(URIDereferencer) which is able to resolve node which are not yet in the DOM document tree (fragments in XMLObject).

我现在正在向Oracle报告此问题,我将使用错误ID更新答案。

编辑: apache SVN

编辑2:感谢此错误报告,我了解到这是一个XMLId属性处理中的演化。

Edit 2 : Thanks to this bug report I've understood that this was an evolution in XML "Id" attributes handling.

以前版本的java / JSR-105 / SANTUARIO曾对<$ c $中使用的Id属性非常宽容c> document.getElementById(...)但是这个新版本需要一个标识为 ID XML说话的属性。我的意思是命名属性Id或ID不再足够,您需要将其标记为ID,最终通过XSD / DTD架构验证。

Previous versions of java/JSR-105/SANTUARIO used to be very tolerant on "Id" attributes used in document.getElementById(...) but this new version requires an attribute that is identified as ID XML speaking. I mean that naming the attribute "Id" or "ID" is not sufficient anymore, you need to get it marked as ID, eventually by an XSD/DTD schema validation.

不幸的是,我正在遵循一个无效的架构,因此无法通过Java解析。

如果你是在同样的情况下看到我的解决方案。否则,如果您的XML文档确实具有有效的架构,请查看@sherb解决方案 https://stackoverflow.com/a / 17437919/233906

If you are in the same situation see my solution below. Otherwise, if you're XML document does have a valid schema, have a look at @sherb solution https://stackoverflow.com/a/17437919/233906

幸运的是,您可以标记使用 Element.setIdAttributeNode(org.w3c.dom.Attr,boolean)

Fortunately, you can tag an attribute as an ID using methods like Element.setIdAttributeNode(org.w3c.dom.Attr,boolean).

结合一点XPath,如 descendant-or-self :: * / @ Id 来获取 Attr Id节点加上一点Java ((Element)attr.getOwnerElement())。setIdAttributeNode(attr,true)应该让你离开麻烦。

Combining with a little XPath like descendant-or-self::*/@Id to fetch Attr "Id" nodes plus a little Java ((Element)attr.getOwnerElement()).setIdAttributeNode(attr,true) should get you out of trouble.

但要小心: setIdAttributeXXX()仅对当前有效文件&节点。如果你克隆 / 采用 / import 你需要做每个DOM树的新节点上的 setIdAttributeXXX()

But be carefull : setIdAttributeXXX() is valid only for the current document & node. If you clone/adopt/import you need to do a setIdAttributeXXX() on the new nodes of each DOM tree

这篇关于升级到java7u25后,XML dig sig错误的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆