Open shibayan opened 2 years ago
+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.
FYI @safihamid
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 sokulkar@microsoft.com 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.
For more info about the use case: https://medium.com/pernod-ricard-tech/simple-http-redirect-301-or-302-using-azure-functions-proxies-66ec3ce779dc
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 sokulkar@microsoft.com 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 sokulkar@microsoft.com 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:
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
So, what is the latest status on the long term support for proxies here? I, aswell as others, do have a use case where API management is not really the best fit. From a cost perspective it's really bad.
None, think Microsoft realized they made a very cost efficient serverless possibility for reverse proxy, url redirects and all other great use cases and decided to deprecate it :-)
It was suddenly announced that Functions Proxies will be removed from Azure Functions v4.
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.
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.