Endpoint /api/frontend throws UnknownError when configured with AuthType.None about unleash HOT 4 CLOSED

Nice one! I think we should add under "expected outcome":

If no token is supplied, the api should return all toggles belonging to default project and the result of their evaluation
If a token is supplied, the token's environment and project data should be respected.

But what happens if you provide an invalid token? 401 or the same as if no token? I'd lean towards the 401 because that's clearer to the user.

This also isn't entirely true:

The desired behavior is shown in the endpoint /api/client/features which works both with and without token when Unleash is configured with AuthType.None

Because the api/client/features endpoint disregards the token entirely if AuthType is None: so even if you provide a token with a specified enviroment / projects, it disregards it and gives you all projects in the default environment. That's a separate bug, though.

from unleash.

Oh, and for the record: I'm not entirely convinced that allowing you to call the endpoint without a token is the right thing to do, because it feels like we're encouraging it that way, and it probably won't do what you want it to do. However, there is an argument to be made that at least the client and frontend APIs will work the same if we do, so you get a consistent experience.

from unleash.

Thank you @thomasheartman!

I think we should add under "expected outcome":

Done!

But what happens if you provide an invalid token? 401 or the same as if no token? I'd lean towards the 401 because that's clearer to the user.

Yeah that makes sense to me as well!

This also isn't entirely true:

Ugh, I missed that! But yes, separate issue!

I'm not entirely convinced that allowing you to call the endpoint without a token is the right thing to do, because it feels like we're encouraging it that way, and it probably won't do what you want it to do. However, there is an argument to be made that at least the client and frontend APIs will work the same if we do, so you get a consistent experience.

Indeed, this feels like it needs doing now for consistency, but deprecation and clearer use case could be warranted down the road

from unleash.

Closing this now that #6247. It seems the github auto-closer doesn't like the word "and".

from unleash.