Hi,
This is my first post, but I'm trying to follow the guidelines for new threads so please excuse any lack of information or clarity on my question below.
Using Mirth Connect 3.1.1.7461. I haven't posted my channel as it is currently in a mess with multiple versions of different destinations, etc. as I've been trying to fix the issue below. Happy to clean up my channel and post though if that would help over and above my explanation below.
I'm using a single Channel to "transform" a HTTP call from another vendor's product (which is a HTTP POX call) into my products standard HTTP request to invoke/launch our products user interface with user and patient context (the call to our system is a HTTP POST with parameters passed as form data followed by a series of 302 responses and GETs). This will let the user of the other vendors product "launch in context"/invoke our product inside a web browser control in the other vendors product without the user having to login or select the patient again in our product. The outcome I am looking for is to pass back a response to the original request which completely mimics a direct call to our system (i.e. the same response content/body and the same headers and cookies being set). I have to work with the current implementation the other vendor has for configuring links to other systems inside their product.
I have a HTTP Listener source configured and working. It accepts a POST with an XML request body. I parse some values out of the XML and put these in the ChannelMap. I then have a destination which is a Javascript Writer. The Javascript in the destination constructs the HTTP request (with headers, form data, content type, etc.) and POSTs it to our systems standard invocation landing page. The Javascript is based on the very helpful sample provided by @rts in this support forum post.
The Javascript writer destination then processes the response which is a 302 redirect. The Javascript Writer HTTP connection is set NOT to follow the redirect so I can grab data out of the response and pass this to a second destination. The key part is that I extract the 3 Set-Cookie headers and place the key=value combinations into a ChannelMap variable so I can use this to as the Cookie header on the next call. The other key piece of information extracted is the redirect location into the ChannelMap.
Finally I have a HTTP Sender destination which is configured to call the redirect location from the first destination and pass the 3 cookies on the HTTP request. This works correctly and the destination automatically follows several HTTP 302 redirects before the patient homepage is returned in the final response along with a 200 response code.
The original HTTP Listener source is configured to use the response from my last HTTP Sender destination as the content/body passed back to the other vendors system.
Having explained all that, now I can explain the issue: On the response sent back by the source I have the correct content/body going back, but I also need to send the 3 cookie values (as Set-Cookie headers) back to the other vendor's system so our system will see the user as logged in when they click on links returned in the patient homepage by our system.
The issue is that I can only configure a single Set-Cookie key/value pair in the HTTP Listener response headers. This is a known issue - MIRTH-3449 - which has been fixed and looks like it will be included in 3.2 which is excellent.
However I'm not sure when 3.2 will be released? I assume some month's away given 3.1.1 has just come out and I need to find a workaround for the issue now.
To date as a workaround I've tried passing the 3 cookies as the value of a single Set-Cookie response header with each of the pairs separated by a comma. This apparently was allowed in an older RFC (RFC 2109 I think) but is no longer supported in the current RFC 6265 and the test stub I'm using (POSTMAN as a Chrome extension) doesn't recognise the 2nd and 3rd cookie values. I'm also searched using multiple combinations in Google, the Mirth Support form and other sources to try and find an answer/workaround (hence I stubbled across MIRTH-3449).
I was wondering if anyone could help with a workaround using the existing capabilities in Mirth 3.1.1 (i.e. not applying the fix for MIRTH-3449 as a patch)?
Or if someone could help with some pointers on if and how it is possible to patch my Mirth 3.1.1 to apply the fix for MIRTH-3449?
I am comfortable following Javascript (based on samples like the post above) but patching the actual Mirth code may be a bit beyond my technical skills as I'm an solution architect by trade these days and not a coder (though I'm willing to have a go if I can get some pointers).
Thanks in advance,
Mark.
This is my first post, but I'm trying to follow the guidelines for new threads so please excuse any lack of information or clarity on my question below.
Using Mirth Connect 3.1.1.7461. I haven't posted my channel as it is currently in a mess with multiple versions of different destinations, etc. as I've been trying to fix the issue below. Happy to clean up my channel and post though if that would help over and above my explanation below.
I'm using a single Channel to "transform" a HTTP call from another vendor's product (which is a HTTP POX call) into my products standard HTTP request to invoke/launch our products user interface with user and patient context (the call to our system is a HTTP POST with parameters passed as form data followed by a series of 302 responses and GETs). This will let the user of the other vendors product "launch in context"/invoke our product inside a web browser control in the other vendors product without the user having to login or select the patient again in our product. The outcome I am looking for is to pass back a response to the original request which completely mimics a direct call to our system (i.e. the same response content/body and the same headers and cookies being set). I have to work with the current implementation the other vendor has for configuring links to other systems inside their product.
I have a HTTP Listener source configured and working. It accepts a POST with an XML request body. I parse some values out of the XML and put these in the ChannelMap. I then have a destination which is a Javascript Writer. The Javascript in the destination constructs the HTTP request (with headers, form data, content type, etc.) and POSTs it to our systems standard invocation landing page. The Javascript is based on the very helpful sample provided by @rts in this support forum post.
Side note: While this isn't the reason for this post, I had to use a Javascript writer destination as otherwise I couldn't get access to the 3 Set-Cookie headers which are returned in the response headers from our system. I could only access the last Set-Cookie header pair using a Response mapper mapped to "$('responseHeaders').get('Set-Cookie')" in the the Destination's Response Transformer when I was using a HTTP Sender as the destination type. I had to access the Set-Cookie headers in the Javascript writer via their index values as the httpUrlConnection class also only returned the last cookie if I used getHeaderFields('Set-Cookie'). I have searched but cannot find this as a known issue/bug in JIRA?
The Javascript writer destination then processes the response which is a 302 redirect. The Javascript Writer HTTP connection is set NOT to follow the redirect so I can grab data out of the response and pass this to a second destination. The key part is that I extract the 3 Set-Cookie headers and place the key=value combinations into a ChannelMap variable so I can use this to as the Cookie header on the next call. The other key piece of information extracted is the redirect location into the ChannelMap.
Finally I have a HTTP Sender destination which is configured to call the redirect location from the first destination and pass the 3 cookies on the HTTP request. This works correctly and the destination automatically follows several HTTP 302 redirects before the patient homepage is returned in the final response along with a 200 response code.
The original HTTP Listener source is configured to use the response from my last HTTP Sender destination as the content/body passed back to the other vendors system.
Having explained all that, now I can explain the issue: On the response sent back by the source I have the correct content/body going back, but I also need to send the 3 cookie values (as Set-Cookie headers) back to the other vendor's system so our system will see the user as logged in when they click on links returned in the patient homepage by our system.
The issue is that I can only configure a single Set-Cookie key/value pair in the HTTP Listener response headers. This is a known issue - MIRTH-3449 - which has been fixed and looks like it will be included in 3.2 which is excellent.
However I'm not sure when 3.2 will be released? I assume some month's away given 3.1.1 has just come out and I need to find a workaround for the issue now.
To date as a workaround I've tried passing the 3 cookies as the value of a single Set-Cookie response header with each of the pairs separated by a comma. This apparently was allowed in an older RFC (RFC 2109 I think) but is no longer supported in the current RFC 6265 and the test stub I'm using (POSTMAN as a Chrome extension) doesn't recognise the 2nd and 3rd cookie values. I'm also searched using multiple combinations in Google, the Mirth Support form and other sources to try and find an answer/workaround (hence I stubbled across MIRTH-3449).
I was wondering if anyone could help with a workaround using the existing capabilities in Mirth 3.1.1 (i.e. not applying the fix for MIRTH-3449 as a patch)?
Or if someone could help with some pointers on if and how it is possible to patch my Mirth 3.1.1 to apply the fix for MIRTH-3449?
I am comfortable following Javascript (based on samples like the post above) but patching the actual Mirth code may be a bit beyond my technical skills as I'm an solution architect by trade these days and not a coder (though I'm willing to have a go if I can get some pointers).
Thanks in advance,
Mark.
HTTP Sender - setting multiple Set-Cookie headers on the sender response
0 commentaires:
Enregistrer un commentaire