CUMI API - 401 Unauthorized error (Sporadic)

[Beena]

Hello,

Has anyone come across this issue of sporadic 401 unauthorized error?

Mailbox delegate account is used to access user mailboxes via CUMI. 90% of the time it authenticates fine &  gets to user mailboxes/messages. The 401 unauthorized error occurs occasionally & once it starts happening the error continues for a while but later resolves on it's own.  The server is an active-active cluster. The API requests are sent only to the publisher. UC version is 10.0.1.12900-2.

Error Details - HTTP Status 401 -  Unauthorized.  This request requires HTTP authentication.          

[lindborg]

are you sending requests always using basic authentication?  If so that's likely you're issue - starting in 10.0 the security framework (i.e. under Unity Connection and any other product shipping on VOS) restricts basic authentication request coming in to a couple a second - if you pumping requests in faster than that the subsequent ones will all fail... this would appear to be random depending on how fast the requests were coming in.

You need to update your code to be storing the jsessionId values and doing basic authentication requests to fetch a new one only when they expire.

If that's not the case I'm not sure what would be causing that right off hand...

[Beena]

Yes, we're using basic auth. What's the limit on the requests and how many concurrent conn are allowed? Currently we're doing <10 concurrent requests.

[lindborg]

I’m not real sure what you’re meaning of “concurrent requests” is here but it doesn’t really matter – if a series of REST API requests comes in at (I think) 3 or more in a second, the later ones will fail by design. 

To be clear, any application doing REST API work should be doing security properly – that means doing basic authentication, getting your sessionId and checking the headers of responses as you go to know when it’s expiring and issuing another basic request then to get another sessionId – pretty standard stuff and Java  (and .NET and probably others) have libraries intended to make this process fairly easy.  The .NET SDK wrapper I provide for CUPI handles this automatically for instance.

Rather than throttling your requests and/or figuring out how to take it to the very edge it’d be easier and more much more reliable to update your logic for handling authentication correctly I’d think.

[Beena]

Well..we have multiple windows services sending cumi/cupi requests. The recommendation earlier from the Cisco team was to not to exceed 10 requests at any give point of time. Anyways, thanks for the feedback.

[lindborg]

Up to 10 sessions should be supportable (as is 10 ODBC connections by default for instance) - I don't think that's your issue - I'm assuming each session is getting it's own SessionId (i.e. you're authenticating as a different user?) - not sure without seeing much more detail about your HTTP request/response headers for your application.

If each of your services is doing it's own session management and each one is only sending basic authentication once and keeping the sessionIds in shape and renewing them as necessary that should work - I've done this for load testing tools with my CUPI SDK for 3 or 4 at a time without issue (never tried 10 but I don't see why it would be an issue).

I suspect, but don't know, that each of your sessions is doing a series of HTTP request responses and you're sending basic authentication with all of them and they come in fast enough at times to hit the rejection threshold - but that's just an assumption based on what little I know about your service setup.

[Beena]

The windows services are multi-threaded. auth credentials is the same for all  threads - (mailbox delegate account).  each thread sends basic auth.