Azure AD proxy Connector gateway Timeout
As per Azure AD guideline, Only "Default" and "Long" Application time out value can be assigned to Azure application. Default = 85 seconds and Long = 180 Minutes. But i have few application which takes more than 3 minutes to respond on few UI actions. I am wondering, if we can have a way to override the proxy connector application time out settings. We may consider providing a way in Proxy Connector window service installed on server to increase Backend application timeout.
Thank you for sharing your feedback.
The timeout limit was defined due to two main motivations 1. Security and service SLA 2. The nature of network products and user productivity.
In terms of security, App Proxy is a multi-tenant service and in today’s time and the high load we’re experiencing on our system, we have a limited ability to allow connections to be open for such a long time. Allowing such timeouts will widen our attack surface significantly and reliability of our service.
In terms of productivity, we are dealing with a multi- hop network bound service (traffic from the user browser, to our service, to a connector and to the app). In such an environment there may be impact to parts of the system by adding in this longer timeout. When there is no activity on the wire of a network service it is questionable if the connection is really alive.
This would also solve our issue with using JDEdwards Enterprise One with AAADAP and some jobs take more the the upper limit of 180 Seconds (Long). Is there a specific reason why this is limited to this value? I have been told by our ERP team that it could take up to 20 minutes at times to receive a response.
Thanks Martin for the Idea! Actually I have legacy applications which have actions taking more than 3 minutes to return the data from SQL server. There are so many applications. So we can't optimize them or re-write the applications in short time frame. That's why, i was wondering to have some feature in Azure to solve my purpose.
Martin Hobson commented
I've been fighting with this same issue where we have an application that processes uploaded files. During the parse/save phase the open HTTP connection "goes quiet" and the app doesn't generate the actual "done" page content until the input is completely consumed (several minutes). This probably breaks some of the basic app design guidelines, but here we are... In any case, my workaround was to modify the app to send *some* traffic back as it processes the contents. This seems to keep the connection alive BUT the contents aren't forwarded to the client very enthusiastically - rather, the proxy buffers the content rather unpredictably. Anyway, at least the connection isn't dropped and the user gets an "all done" response successfully.
Maybe this would work in your case. Maybe...