Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TransformerConfigurationException during processing of HTTP response with Set-Cookie: HttpOnly;Secure;SameSite=Lax header #19

Open
jbienkowski opened this issue Jan 24, 2024 · 4 comments

Comments

@jbienkowski
Copy link

Dear all,

The configuration of the KNMI servers providing seismic data has been recently altered with the introduction of an additional HTTP response header:

Set-Cookie: HttpOnly;Secure;SameSite=Lax

It seems that this causes the irisFetch library to fail - please see our case below:

Matlab statement:

javaaddpath('/home/user/tools/IRIS-WS-2.20.1.jar')
s = irisFetch.Stations('station','NL,NR','*','*','*Z','BASEURL','http://rdsa.knmi.nl/fdsnws/station/1/'); % for KNMI

Exception:

{Transfer-Encoding=[chunked], Keep-Alive=[timeout=5, max=100], null=[HTTP/1.1 200 OK], Access-Control-Expose-Headers=[WWW-Authenticate], Server=[SeisComP-FDSNWS/1.2.4], Access-Control-Allow-Origin=[*], Connection=[Keep-Alive], Set-Cookie=[HttpOnly;Secure;SameSite=Lax], Access-Control-Allow-Headers=[Authorization], Date=[Tue, 23 Jan 2024 13:47:19 GMT], Content-Type=[application/xml]}
http://rdsa.knmi.nl/fdsnws/station/1/query?net=NL,NR&sta=*&cha=*Z&loc=*&level=station&format=xml:null
Jan 23, 2024 2:47:20 PM com.sun.xml.internal.bind.v2.util.XmlFactory createTransformerFactory
SEVERE: null
javax.xml.transform.TransformerConfigurationException: Unsupported feature: http://javax.xml.xmlconstants/feature/secure-processing
    at com.icl.saxon.TransformerFactoryImpl.setFeature(TransformerFactoryImpl.java:373)
    at com.sun.xml.internal.bind.v2.util.XmlFactory.createTransformerFactory(XmlFactory.java:169)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.createTransformerHandler(JAXBContextImpl.java:712)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:60)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:103)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:45)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:559)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:538)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:60)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXEventConnector.handleStartElement(StAXEventConnector.java:246)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXEventConnector.bridge(StAXEventConnector.java:115)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:445)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:415)
    at edu.iris.dmc.service.station.parser.StationXMLParser.parse(StationXMLParser.java:151)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:314)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:262)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:272)

Error using irisFetch/Networks/fetchTheStations (line 809)
Java exception occurred:
java.lang.IllegalStateException: javax.xml.transform.TransformerConfigurationException: Unsupported feature:
http://javax.xml.xmlconstants/feature/secure-processing
    at com.sun.xml.internal.bind.v2.util.XmlFactory.createTransformerFactory(XmlFactory.java:173)
    at com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.createTransformerHandler(JAXBContextImpl.java:712)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.DomLoader$State.<init>(DomLoader.java:60)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.DomLoader.startElement(DomLoader.java:103)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.ProxyLoader.startElement(ProxyLoader.java:45)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext._startElement(UnmarshallingContext.java:559)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.startElement(UnmarshallingContext.java:538)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.InterningXmlVisitor.startElement(InterningXmlVisitor.java:60)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXEventConnector.handleStartElement(StAXEventConnector.java:246)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.StAXEventConnector.bridge(StAXEventConnector.java:115)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:445)
    at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:415)
    at edu.iris.dmc.service.station.parser.StationXMLParser.parse(StationXMLParser.java:151)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:314)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:262)
    at edu.iris.dmc.service.StationService.fetch(StationService.java:272)
Caused by: javax.xml.transform.TransformerConfigurationException: Unsupported feature:
http://javax.xml.xmlconstants/feature/secure-processing
    at com.icl.saxon.TransformerFactoryImpl.setFeature(TransformerFactoryImpl.java:373)
    at com.sun.xml.internal.bind.v2.util.XmlFactory.createTransformerFactory(XmlFactory.java:169)
    ... 15 more

Error in irisFetch.Networks (line 713)
         fetchTheStations();

Error in irisFetch.Stations (line 639)
         [stationStructure, urlParams] = irisFetch.Networks(detailLevel,varargin{:});

Error in make_KNMIloc (line 12)
s = irisFetch.Stations('station','NL,NR','*','*','*Z','BASEURL','http://rdsa.knmi.nl/fdsnws/station/1/'); % for KNMI

We have tested it with FDSNWSs provided by other DCs responding without Set-Cookie: HttpOnly;Secure;SameSite=Lax header and those seem to work fine.

We would be grateful if you could look into this issue. Deleting this header is not permitted according to our security policy, so either a solution or a recommendation on how to address it would be greatly appreciated.

Regards,
Jarek

@rtweekly-iris
Copy link

Hello Jarek - Thanks for providing this information about the additional HTTP header. This error appears to be originating from the underlying IRIS-WS Java library (not with the irisFetch.m file) which is always difficult to troubleshoot and update.

Can you clarify - are your test requests to irisFetch.Stations successful when specifying different values for BASEURL and they only fail when using the rdsa.knmi.nl domain URL? Also, have you found similar results when trying to use irisFetch.Traces with these service endpoints?

It is unclear to me who the current maintainer/developer of that project is currently - we have reorganized much of our staff due to the recent EarthScope merger - but will mark this as a bug to be addressed. Unfortunately I cannot provide a timeline for that to be patched at this time.

@jbienkowski
Copy link
Author

Dear Robert,

We continued to investigate this issue. First, we have created a reverse proxy that removed Set-Cookie header, but it did not solve the issue. After more tests we have confirmed this is related purely to metadata content:

Matlab code:

s = irisFetch.Stations('station','NL','HGN','*','BHZ','BASEURL','http://rdsa.knmi.nl/fdsnws/station/1/');

Our original metadata (failing):

<?xml version="1.0" encoding="UTF-8"?>
<FDSNStationXML xmlns="http://www.fdsn.org/xml/station/1" schemaVersion="1.1">
    <Source>SeisComP</Source>
    <Sender>ODC</Sender>
    <Created>2024-02-02T10:36:36.009327</Created>
    <Network code="NL" startDate="1993-01-01T00:00:00" restrictedStatus="open">
        <Description>Netherlands Seismic and Acoustic Network</Description>
        <Identifier type="DOI">10.21944/e970fd34-23b9-3411-b366-e4f72877d2c5</Identifier>
        <Station code="HGN" startDate="2001-06-06T00:00:00" restrictedStatus="open">
            <Identifier type="contractor">KNMI</Identifier>
            <Latitude>50.764</Latitude>
            <Longitude>5.9317</Longitude>
            <Elevation>135</Elevation>
            <Site>
                <Name>Heimansgroeve</Name>
                <Country>The Nederlands</Country>
            </Site>
            <CreationDate>2001-06-06T00:00:00</CreationDate>
        </Station>
    </Network>
</FDSNStationXML>

Then we have decided to temporarily drop the station contractor identifier element (<Identifier type="contractor">KNMI</Identifier>) from StationXML and the problem disappeared. We have also successfully tested it against NL metadata provided via service.iris.edu which luckily is a bit outdated and does not include <Identifier/> elements on the station level. It is important to notice that DOI on network level is not causing any issues.

I am wondering what are your thoughts here, would it be possible to come up with a fix in the irisFetch? We would naturally prefer not to remove this information from our metadata. I think the future plans for StationXML include addition of <Contributor/> element which would be a better fit here, but for now we do not see better better option.

Thanks a lot,
Jarek

@chad-earthscope
Copy link

Hi Jarek,

First, it's does seem like a bug in our support library, that your Identifier usage is causing problems.

I do not think Identifier is a good fit for identifying a "contributor". I wonder if the Operator element might be a better fit?
https://docs.fdsn.org/projects/stationxml/en/latest/reference.html#station-operator

I am wondering what are your thoughts here, would it be possible to come up with a fix in the irisFetch?

The issue is likely not in irisFetch.m itself, but in the Java IRIS-WS.jar library that it uses. A fix for this library is not expected soon given our current resources.

@jbienkowski
Copy link
Author

Hi Chad,

Thanks for your reply. We have internally considered using the Operator element, but decided this could be a bit misleading, because for some stations KNMI acts as the operator while being financially or logistically backed by an external entity (e.g. NL.G230).

If I remember correctly, I have seen Contributor element wish-listed in one of the WG3 reports. It seemed like an ideal fit, but it may be some time before we observe its implementation, right?

Also, as a walk-around for this particular problem we considered loading StationXML from file with our unfortunate Identifier elements removed, but I have no idea if there is an irisFetch substitute for that, could you perhaps suggest something?

Thanks a lot,
Jarek

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants