Allow control of the ARRAffinity set cookie response header
Problem:
When a request for contoso.com hits an Azure App Gateway and the back end is routed to contoso.azurewebsites.com, the set ARRAffinity cookie response includes the optional domain attribute (as per RFC6225 Page 22) that specifies "contoso.azurewebsites.net". causing the user agent to never write the cookie since the Domain attribute doesn't match the requested domain.
Proposed Solutions:
Solution #1
Give us a way to disable the Set Cookie: domain attribute similar to the way we can add a "Arr-Disable-Session-Affinity" response header to disable the cookie entirely. I'm suggesting an "Arr-Disable-Session-Affinity-Strict-Domain" response header to tell the ARR proxy not to write the Domain attribute in the Set Cookie header, The User agent can then decide the correct domain.
Solution #2
Give us a "Arr-Session-Affinity-Domain" response header that lets me set the correct domain (as pulled from the X-Original-Host header in the request).
Solution #3
Have the ARR software that injects the set cookie header honor the X-Original-Host header inserted by the App Gateway and use that when setting the ARRAffinity cookie.
Any one of these solutions would be preferable to requiring me to set a custom domain and additional SSL certificate on my app service.
Anonymous
shared this idea
2 comments
-
Anonymous
commented
you mean https://tools.ietf.org/html/rfc6265, not 6225
-
Anonymous
commented
Solution #4
I don’t know if responses from the app service are routed directly back to the user agent or if they travel back through the application gateway (AG).
If response traffic is routed through the AG on its way back to the user agent, the AG would have all the information required to rewrite the domain in the set ARRAffinity cookie header. The logic flow would look something like this:1. A user agent request comes in on the AG frontend listener bound to “contoso.com”.
2. The AG routes the request to the backend app service which has the default binding of “contoso.azurewebsites.com”.
3. The app service processes the request and generates a response.
4. The response arrives at the AG on its way back to the user agent. The response contains a “Set ARRAffinity cookie” header with “Domain=contoso.azurewebsites.com” attribute set.
5. Since the AG knows the frontend listener hostname and the backend app service hostname it could modify the “set ARRAffinity cookie” response header, rewriting the domain attribute from the backend hostname “contoso.azurewebsites.com” to the front end listener hostname “contoso.com”.
6. The response would then be sent on to the user agent who will store the cookie (since the domain matches the request hostname).
7. Now that the user agent has a valid ARRAffinity cookie, it gets sent on subsequent requests as intended.I like this approach because it is internal to the app gateway which prevents a rouge user agent that might purposely bypass the AG but include an X-Original-Host request header in an effort to spoof an AG. In essence, the AG will be solving the very problem it creates without involving custom code in the app service or modification to any other Azure services. I don’t see a scenario where this would not be the desired functionality but if there is one, the AG configuration could include a “Use front end hostname for ARRAffinity cookie” checkbox option.