AlwaysOn with AuthLevel.FUNCTION fails - need guidance for FastAPI + authenticated warmup

[Molier]

Related to #9109 which identified that AlwaysOn uses /admin/warmup endpoint.

Issue

We're seeing 401 errors with AlwaysOn when using AuthLevel.FUNCTION with FastAPI on Azure Functions. The /admin/warmup endpoint used by AlwaysOn doesn't include function keys, causing authentication failures.

Current setup

# function_app.py
import azure.functions as func
from fastapi import FastAPI

fast_app = FastAPI()
app = func.AsgiFunctionApp(app=fast_app, http_auth_level=func.AuthLevel.FUNCTION)

• Premium plan with AlwaysOn enabled
• Function authentication level set to FUNCTION

Attempted solutions

1. Added web.config to scripts folder:

<?xml version="1.0" encoding="UTF-8" standalone="no">
<configuration>
    <system.webServer>
      <rewrite>
        <rules>
          <rule name="Rewrite AlwaysOn" stopProcessing="true">
            <match url="^$" />
            <conditions>
              <add input="{HTTP_USER_AGENT}" pattern="^AlwaysOn$" />
            </conditions>
            <action type="Rewrite" url="/api/Online/Ping" />
          </rule>
        </rules>
      </rewrite>
    </system.webServer>
</configuration>

Result: Configuration does not get deployed to wwwroot

2. Tried WEBSITE_WARMUP_PATH setting
   Result: Documentation confirms this doesn't affect AlwaysOn path

Logs

2024-04-04T05:58:14Z [Information] Executing StatusCodeResult, setting HTTP status code 401

Key Questions

1. Is there a way to set different auth levels per route while keeping app-level auth?
2. Can we configure AlwaysOn to use function keys?
3. What's the recommended approach for FastAPI apps that need both security and AlwaysOn?

Environment

• Python 3.11
• Azure Functions runtime v4
• FastAPI on Azure Functions
• Authentication Level: FUNCTION
• Hosting: Premium plan

extra context

• https://www.thebestcsharpprogrammerintheworld.com/2018/08/23/how-to-optimize-azure-app-service-alwayson-cold-start-warm-up-request/
• https://learn.microsoft.com/en-us/azure/app-service/reference-app-settings?tabs=kudu%2Cdotnet

Please provide guidance on the recommended approach to handle this authentication scenario without compromising security by switching to AuthLevel.ANONYMOUS.

[Molier]

I've tested a similar approach that also fails when deployed to Azure, though it works locally. This highlights an important aspect of the issue that might help guide the solution:

import azure.functions as func
from fastapi import FastAPI

# Define FastAPI app with root endpoint
app_fastapi = FastAPI()
@app_fastapi.get("/")
async def root():
    return {"status": "OK"}

# Main ASGI app with function-level auth
app = func.AsgiFunctionApp(app=app_fastapi, http_auth_level=func.AuthLevel.FUNCTION)

# Attempted anonymous root route for AlwaysOn
@app.route("/", auth_level=func.AuthLevel.ANONYMOUS)
def root_function(req: func.HttpRequest) -> func.HttpResponse:
    return func.HttpResponse(
        status_code=200, 
        body='{"status": "OK"}', 
        mimetype="application/json"
    )

While this implementation appears to solve the issue locally:

• Root endpoint works without authentication
• Other routes maintain FUNCTION level security
• FastAPI integration functions correctly

However, when deployed to Azure, it still results in the same 401 unauthorized errors:

[Information] Authorization failed. These requirements were not met:
Microsoft.Azure.WebJobs.Script.WebHost.Security.Authorization.FunctionAuthorizationRequirement
[Information] Executing StatusCodeResult, setting HTTP status code 401

This suggests that the route-level auth_level=func.AuthLevel.ANONYMOUS declaration isn't being respected in the Azure environment, even though it works in local development. There seems to be a fundamental difference in how auth levels are processed between local and cloud environments that needs to be addressed.

The fact that this approach works locally but fails on Azure points to a potential platform-level issue with how route-specific authentication levels are handled in the Azure Functions host when using FastAPI integration.

Would appreciate insights into:

1. Why route-level auth settings behave differently in cloud vs local
2. If there's a way to properly override auth levels for specific routes in Azure
3. The recommended pattern for handling AlwaysOn with FastAPI while maintaining security