This is probably OK, but something about letting things through the proxy to the app without auth is making me nervous. Would it work if we just respond with a 204 here?

Also thank you for working on this!

And I suppose we will need to do the same for the path-based proxy.

Actually, I suppose we have to let it through because it could be a 404 or something else, no way to know for sure that particular preflight will actually be a 204.

Will approve once we add it to the path proxy as well!

Sorry to keep going back and forth 😅

But I was thinking if we do pass it through, that exposes information (which ports have things on them) and maybe we should just hardcode a 204 after all...trying to see what other things do like oauth2-proxy to see if there is some standard. edit seems they have a skip-auth-preflight flag?

What do you think is the right direction here? A skip-auth-preflight flag is definitely an option, but hardcoding adds a layer of security by obscurity. However, hardcoding 204 kind of defeats the purpose of preflighting requests.

hardcoding 204 kind of defeats the purpose of preflighting requests

Yeah, you are right, but the attack surface is large since we automatically forward every port, so it makes me nervous. A hardcoded response would eliminate the attack vector, and would probably be good enough for development?

But, I think for now my vote would be to gate this behind a skip-auth-preflight flag set to false by default. Or I suppose it could take a list of port numbers.

What do you think?

We can start off with a boolean skip-auth-preflight flag which can later be extended with a list of ports or a hardcoded mode?

That sounds good to me!

@code-asher Have a look and see if these changes make sense to you.