Unauthorized Access to endpoints in production

[Caden-Ertel]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Any log messages given by the failure

Failed to load resource: the server responded with a status of 403 (Forbidden) -> /config
Failed to load resource: the server responded with a status of 403 (Forbidden) -> /chat

azd version?

run azd version and copy paste here.

1.8.2

Mention any other details that might be useful

USE_AUTH and ENFORCE_ACCESS_CONTROL are set to True

The code functions properly locally, can chat to the bot via login/group-based auth via ACL and app registrations, no errors

In prod, the frontend can successfully GET /auth_setup but receives a 403 to /config which I'm not sure how that would be possible as its a non-auth needed endpoint
additionally, if i visit /config via the browser I get the correct response

finally,
chat does not work at all

Attempts to fix

Added web app URL to CORS - ALLOWED_ORIGINS

[pamelafox]

Hm, our fetching code is slightly different:

export async function configApi(): Promise<Config> {
    const response = await fetch(`${BACKEND_URI}/config`, {
        method: "GET"
    });

    return (await response.json()) as Config;
}

versus

async function fetchAuthSetup(): Promise<AuthSetup> {
    const response = await fetch("/auth_setup");
    if (!response.ok) {
        throw new Error(`auth setup response was not ok: ${response.status}`);
    }
    return await response.json();
}

So I wonder if BACKEND_URI is confusing it. What do you see in the network requests of your browser for that request? You could try changing that fetch to just "/config", if you dont have any need to override BACKEND_URI.

[Caden-Ertel]

Switching to just /config still results in a 403.

I guess something else to note is that the .auth/me and .auth/refresh don't resolve either, which might another factor in this issue?

is there a reason why the config api request needs to have token sent in authorization headers?

Also, is there a place where you can see the logs that is outputted from the gunicorn server? as opposed to just the app service logs

[pamelafox]

If .auth* routes are not working, then your App Service built-in authentication is not set up properly. A correct setup looks like this in the Portal:

But I don't think we've made it a strict requirement that App Service built-in auth must be setup, since we also use the MSAL SDKs to handle authentication. Do you perhaps have a partially setup built-in auth that's messing with stuff? Do you see anything on that authentication page?

I have tips here for viewing App Service logs:
https://github.com/Azure-Samples/azure-search-openai-demo/blob/main/docs/appservice.md
I usually download them. You may need to increase your log level to see more logs, since it defaults to WARNING level in production.

[Caden-Ertel]

My auth settings page is identical to yours...

HOWEVER,

Seeing the difference in code you posted versus what version of the repo we had was an issue:

Yours:

export async function configApi(): Promise<Config> {
    const response = await fetch(`${BACKEND_URI}/config`, {
        method: "GET"
    });

    return (await response.json()) as Config;
}

Ours:

export async function configApi(idToken: string | undefined): Promise<Config> {
    const response = await fetch("/config", {
        method: "GET",
        headers: getHeaders(idToken)
    });

    return (await response.json()) as Config;
}

Ill probably need to pull the latest version and then see if those issues still persist, at least on first test, the new version of the code fixed the 403 issue with config

[pamelafox]

Ah, yes, I removed getHeaders as I realized the backend wasn't using it. Glad it's working better.

[Caden-Ertel]

Ok, I'm still seeing 403 errors accessing /chat, even though the same auth method is working for a local development

not seeing any exceptions in Azure Monitor, nor is anything showing up in App Service Logs with the logging level set to INFO