web stats
https posts - using preemptive authorization? - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 11-29-2012, 11:24 AM
lueckep lueckep is offline
OBX.2 Kenobi
 
Join Date: Jul 2011
Posts: 73
lueckep is on a distinguished road
Default https posts - using preemptive authorization?

I've got an HTTPS sender that's giving me some intermittent issues connecting to the destination server. After looking at it, their support has come back to me with the question of "are you using preemptive authorization?"

I'm not sure what the answer is ... Can anyone tell me if that's a function of how I have the channel setup in Mirth? Or is it always going to be yes/no based on how Mirth does it behind the scenes?

I'm on 2.2.1 if it matters
Thanks
Reply With Quote
  #2  
Old 11-29-2012, 11:41 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by lueckep View Post
I've got an HTTPS sender that's giving me some intermittent issues connecting to the destination server. After looking at it, their support has come back to me with the question of "are you using preemptive authorization?"

I'm not sure what the answer is ... Can anyone tell me if that's a function of how I have the channel setup in Mirth? Or is it always going to be yes/no based on how Mirth does it behind the scenes?

I'm on 2.2.1 if it matters
Thanks
The HTTP Sender does preemptively attempt to authenticate, but obviously only if the "Authentication" option is set to Yes on the connector settings. There's currently no way to tell the connector to authenticate only if a request comes from the server; is that what you mean?

Update: I've added the following issue for including preemptive authentication as an option: MIRTH-2282
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.

Last edited by narupley; 11-29-2012 at 11:48 AM.
Reply With Quote
  #3  
Old 11-29-2012, 12:03 PM
lueckep lueckep is offline
OBX.2 Kenobi
 
Join Date: Jul 2011
Posts: 73
lueckep is on a distinguished road
Default

Thanks Nick. No, I don't think they're looking for some kind of interactive authentication but we'll see when I respond back to them.

For what it's worth, I do have authentication set to yes (type: basic) and have provided a login and password that usually works fine. But I occasionally get back the following error from them:
com.wm.app.b2b.server.AccessException: [ISS.0084.9004] Access Denied

This triggers me to queue up the message and retry it. I'm always successful on the first retry. I've noticed that the error tends to only come after a small period of inactivity. So I can successfully put as many messages as I'd like as long as they all come in close succession to each other. But if the channel sits idle for a couple minutes, the next message is usually doomed to fail. This leads to us getting many errors over night or during other periods of low traffic.

Google told me that this issue probably represented some issues with the settings on their end so I had punted it to their team to investigate and this is the first response back from them - asking if I'm using preemptive auth.
Reply With Quote
  #4  
Old 11-29-2012, 12:35 PM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by lueckep View Post
Thanks Nick. No, I don't think they're looking for some kind of interactive authentication but we'll see when I respond back to them.

For what it's worth, I do have authentication set to yes (type: basic) and have provided a login and password that usually works fine. But I occasionally get back the following error from them:
com.wm.app.b2b.server.AccessException: [ISS.0084.9004] Access Denied

This triggers me to queue up the message and retry it. I'm always successful on the first retry. I've noticed that the error tends to only come after a small period of inactivity. So I can successfully put as many messages as I'd like as long as they all come in close succession to each other. But if the channel sits idle for a couple minutes, the next message is usually doomed to fail. This leads to us getting many errors over night or during other periods of low traffic.

Google told me that this issue probably represented some issues with the settings on their end so I had punted it to their team to investigate and this is the first response back from them - asking if I'm using preemptive auth.
In that case, you are preemptively authenticating. If you had a username of "foo" and password of "bar", then essentially it's the same as if you added a new header to the Headers table with the Name "Authorization" and the Value "Basic Zm9vOmJhcg==".

That does seem like it's an issue on their end, because assuming that the credentials are correct, there's no reason why a period of inactivity should cause a preemptively authenticated HTTP request to fail.
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #5  
Old 01-10-2013, 04:53 AM
lueckep lueckep is offline
OBX.2 Kenobi
 
Join Date: Jul 2011
Posts: 73
lueckep is on a distinguished road
Default

I finally got another response from the vendor on this issue:

"...we have a global setting that will end a session if the HTTP connection has been idle for more than 2.5 minutes. When the session times out our server sends back a 401 response to your system (Mirth) which is a request for authentication. I’m wondering if the 401 response is causing the issue. Will you please check to see if your system responds to a 401 response by resending a request immediately (along with the auth header) or not?"

The 2.5 minute timeout matches exactly with when we are seeing the issue so I think we're barking up the right tree here but I can't answer her question. I can monitor the traffic on our server but don't know how to decrypt it to make sense of it.
Reply With Quote
  #6  
Old 01-10-2013, 08:08 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by lueckep View Post
I finally got another response from the vendor on this issue:

"...we have a global setting that will end a session if the HTTP connection has been idle for more than 2.5 minutes. When the session times out our server sends back a 401 response to your system (Mirth) which is a request for authentication. Iím wondering if the 401 response is causing the issue. Will you please check to see if your system responds to a 401 response by resending a request immediately (along with the auth header) or not?"

The 2.5 minute timeout matches exactly with when we are seeing the issue so I think we're barking up the right tree here but I can't answer her question. I can monitor the traffic on our server but don't know how to decrypt it to make sense of it.
Well, since you're preemptively authenticating at all times (by way of setting Authentication: Yes in the settings), that "Authorization" header should be present at all times. So even after 2.5 minutes have elapsed, the next request the Mirth channel sends will still contain that header no matter what.

When their server detects a timeout, the current session is invalidated and any clients are expected to authenticate again. The next time the Mirth HTTP Sender sends a message, it is authenticating (by including that header), and yet their server responds with a 401 code anyway. The issue appears to be that once a session ends, they always reject the first new request, whether or not it's correctly authenticating. Instead, their server should just always check for the Authorization header, and if the previous session timed out, it should use that header for renewal.

Really it sounds like something they should fix on their side, but you could also band-aid it on your side basically by making a clone of your HTTP Sender destination. Basically you would have two identical destinations, except that the second one would have a filter that checks the response status of the previous destination and only allows a message to pass through if the previous destination failed. Like this:

Code:
return $r('Destination 1').getStatus() == 'FAILURE';
In that case, if you're using persistent queues, you would have to turn off queuing for the first destination and leave it on for the second destination. That would ensure that the first destination always attempts to dispatch before the channel moves on to the second destination.

Currently in 2.2.1, any response code >= 400 results in an automatic ERROR by the HTTP Sender. In 3.0, our advanced queue settings for all connectors and the response transformer will make this whole convoluted issue easy to handle; basically you will be able to turn on queuing for the HTTP Sender, and then use a response transformer to check for 401 response codes and return QUEUED instead (indicating that the channel should continue to queue the message rather than error it out).
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #7  
Old 01-10-2013, 09:06 AM
lueckep lueckep is offline
OBX.2 Kenobi
 
Join Date: Jul 2011
Posts: 73
lueckep is on a distinguished road
Default

Thanks Nick. She made it sound like they send the 401 code as soon as they hit the timeout, not just as a response to the first message after a timeout. I'm thinking that's the issue - is Mirth hanging onto that 401 and just applying it to the next message we try to send? Either way, I agree that this sounds like a problem on their end still ... just trying to better understand it.

I may use your workaround as I suspect they're not going to change their end so thanks for that too.
Reply With Quote
  #8  
Old 01-10-2013, 10:20 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by lueckep View Post
Thanks Nick. She made it sound like they send the 401 code as soon as they hit the timeout, not just as a response to the first message after a timeout. I'm thinking that's the issue - is Mirth hanging onto that 401 and just applying it to the next message we try to send? Either way, I agree that this sounds like a problem on their end still ... just trying to better understand it.

I may use your workaround as I suspect they're not going to change their end so thanks for that too.
That could very well be the issue; if they're sending a 401 not as a response to a request but as a standalone transmission, then the next time Mirth sends a message and reads from the socket input stream it might be picking up that first 401 message and using that, even if they immediately respond with a 200. So it could even get into a situation where now the response you get back was actually meant for the previous message. So it's like:
  • Client sends request1
  • Server reads request1 and sends response1 (200)
  • Client reads response1 (200), success
  • 2.5 minutes elapse
  • Server sends 401
  • Client sends request1
  • Server reads request2 and sends response2 (200)
  • Client reads 401 (since that's what was first sent by the server), error
  • Client sends request3
  • Server reads request3 and sends response3 (200)
  • Client reads request2 (now the ACKs are out-of-sync, even though the message is processed successfully)
  • ...

Anyway that's only a guess; you would have to capture the network traffic to confirm what's happening. When an error like this occurs, do all subsequent messages error out, or is it just an island error? If it's the latter, that would further suggest that the above traffic flow is what's happening.

If they are sending the 401 right away instead of as a response to a request, that is not valid HTTP/1.1. HTTP is a request-response protocol, so the server should only send a single message after a single request is received. So it sounds like it's definitely something they should fix on their side. But yeah, you can also try using the two-destination trick and let them know that you are very graciously going to still support their non-standard web server implementation. =P
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #9  
Old 04-03-2013, 05:16 AM
lueckep lueckep is offline
OBX.2 Kenobi
 
Join Date: Jul 2011
Posts: 73
lueckep is on a distinguished road
Default

FYI - I finally got tired of these alerts and decided to implement Nick's workaround of having two destinations and trying to send the message twice before giving up on it. It works well - the only catch was that I had to put a hang command in the 2nd destination as they were trying to send too quickly and the client server was still rejecting the 2nd destination as well:

if ($r('INPC-PROD-1st attempt').getStatus() == 'FAILURE') {
//intentional 10 sec pause to add some space between the 1st and 2nd attempt
java.lang.Thread.sleep(30000);
return true
}
else {
return false
}
Reply With Quote
  #10  
Old 04-03-2013, 07:14 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by lueckep View Post
FYI - I finally got tired of these alerts and decided to implement Nick's workaround of having two destinations and trying to send the message twice before giving up on it. It works well - the only catch was that I had to put a hang command in the 2nd destination as they were trying to send too quickly and the client server was still rejecting the 2nd destination as well:

if ($r('INPC-PROD-1st attempt').getStatus() == 'FAILURE') {
//intentional 10 sec pause to add some space between the 1st and 2nd attempt
java.lang.Thread.sleep(30000);
return true
}
else {
return false
}
Glad to hear it; as I mentioned before, that'll be much easier to implement in 3.0 with the new queuing system and response transformer.
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 01:48 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation