Azure-Functions
Azure-Functions copied to clipboard
Azure
Use Cases Lost with the Removal of Functions Proxies in Function V4
It was suddenly announced that Functions Proxies will be removed from Azure Functions v4.
Azure Functions Proxies are no longer supported in 4.x. You are recommended to use Azure API Management.
https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions?tabs=csharp%2Cv4#breaking-changes-between-3x-and-4x
It is unacceptable for users to remove frequently used functions without any notice of discontinuation. Deletion without communication with the user will lead to distrust of the product.
The breaking changes in Functions V4 were identified in the Proposal in the repository below, but the Proxies were removed without a Proposal being created.
https://github.com/Azure/azure-functions/issues?q=is%3Aissue+label%3A%22Breaking+Change%3A+Approved%22+is%3A%22closed+OR+open%22
We believe that we are recommending a move to the Consumption Tier of API Management, but the current APIM Consumption Tier lacks some features and does not fully cover the use cases of Functions Proxies.
Domain root level access
Requests to override the Azure Functions route level and return static pages have all been accomplished using Functions Proxies.
- https://github.com/Azure/azure-functions-host/issues/848#issuecomment-281696890
The members of the development team had consolidated their requests for root level access into this issue. In other words, it is a feature that cannot be achieved without using proxies.
Easy Auth
While API Management is only for APIs, Functions Proxies have also been used to deliver web applications. Its flexibility has been a big advantage.
VNET Integration
The Consumption Tier of API Management cannot configure VNET Integration, and therefore cannot achieve a secure network design. This is a requirement for enterprise applications, but is easily achieved in Azure Functions Proxies.
Managed certificate
Currently, Managed certificate is only provided for CDN / Front Door / App Service, and API Management does not provide a quick HTTPS protected API like App Service.
+1
I think that a combination of Functions Proxy with Easy Auth enables modern secure auth layer in front of the apps without any coding. It really helps securing apps which cannot use app services directly because of the platform limitation.
Ping.
Is there any progress on this issue? I want you to understand the use case because it is too late after Proxies are removed in GA.
We need a work-around for this as we migrate to .NET 6 and Functions V4. We have 50+ function apps and the majority use Proxies. It's not reasonable to expect us to migrate all of these to API Management. It is also not a cost-effective solution for us.
Just to help with the V3 to V4 upgrade scenario, we plan to add Proxy support back to V4 in the next few months, but we won't be adding any new capabilities to it. Using APIM instead is still strongly recommended. I would like to better understand your concerns migrating to APIM so we can improve that experience. Please reach out to me at [email protected] if you would like to chat.
@kulkarnisonia16 great to hear that proxy support is coming back to V4. Hereby some use cases which are not support with APIM.
- We use azure function proxy to create redirects from non www (root) to www domains. APIM and frontdoor are not working for this because they don't have an IP adress to which the A record in the DNS can point. With custom domain and managed SSL certificate on azure function plans this is a easy way to have domain redirection in place in Azure.
For more info about the use case: https://medium.com/pernod-ricard-tech/simple-http-redirect-301-or-302-using-azure-functions-proxies-66ec3ce779dc
- We use azure function proxy to redirect /api calls from a SPA app (for example Nuxt) in azure static webapp to our .NET API. This allows us to configure the backend api url within the azure function proxy per enviroment while the SPA can be static rendered with a relative path to /api for more information: https://blog.danielreis.dev/using-function-proxies-with-azure-static-web-apps
In my opinion the azure functions proxy are really powerfull and it would be good to have them back in version 4.
We use them for delivering SPA app files from Blob Storage. They're needed to add security headers such as Content-Security Policy. At least the old Azure CDN couldn't do that because the rule system is very inflexible.
Two alternatives to Azure Functions Proxies have been developed. I hope they will be of help to others in the same situation as me.
https://github.com/shibayan/azure-functions-http-api https://github.com/shibayan/AppServiceProxy.SiteExtension
Just to help with the V3 to V4 upgrade scenario, we plan to add Proxy support back to V4 in the next few months, but we won't be adding any new capabilities to it. Using APIM instead is still strongly recommended. I would like to better understand your concerns migrating to APIM so we can improve that experience. Please reach out to me at [email protected] if you would like to chat.
When will the functionality be added back to v4?
Just to help with the V3 to V4 upgrade scenario, we plan to add Proxy support back to V4 in the next few months, but we won't be adding any new capabilities to it. Using APIM instead is still strongly recommended. I would like to better understand your concerns migrating to APIM so we can improve that experience. Please reach out to me at [email protected] if you would like to chat.
@kulkarnisonia16 Any update on this? Also tried to reach you on the email address you provided but got no reply. If you indicate you are open to chat it would be nice to get a reply.
@kulkarnisonia16 , I can only agree with the others and confirm again, that proxies is an extremely useful feature. Dropping it would be a very significant loss for the platform. Here is another sample use case, in which proxies are vital and indispensable. An Azure Static Web App, that authenticates users with server-directed flow (cookie-based) and then allows them to securely communicate with an Azure Search instance. Proxies used to proxy HTTP requests towards Azure Search REST API and to append the api-key to those requests. So here they basically serve two purposes:
- The API is accessible by authenticated users only. Proxy endpoints share DNS name with UI, so requests towards them get the same auth cookie attached and therefore are automatically authorized.
- The api-key is not exposed to the public (as it is only being appended on the backend side).
In other words, in this use case proxies convert Static Web App's built-in cookie-based auth into an api-key-based auth:
graph LR
SPA[Client SPA] -->|cookie-based auth| Proxy[Function Proxy]
Proxy -->|api-key auth| API[Azure Search REST API]
, thus allowing to easily and elegantly solve this and many other similar scenarios. Yet it would not be possible to achieve the same with APIM: APIM endpoints are hosted on a different DNS name, so we couldn't avail from Static Web App's cookie-based auth and instead at least would be required to implement a custom client-side (token-based) one. Not to mention extra cost for APIM and overall architectural complications.
We're here to make developer's lives easier, not harder.
Proxies have been re-added in v4 but need a AzureWebJobsFeatureFlags to re-enable it
https://learn.microsoft.com/en-us/azure/azure-functions/legacy-proxies#re-enable-proxies-in-functions-v4x
