Allow OPTIONS requests through domain proxy#7284
Conversation
|
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 |
|
What do you think is the right direction here? A |
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 What do you think? |
|
We can start off with a boolean |
|
That sounds good to me! |
|
@code-asher Have a look and see if these changes make sense to you. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7284 +/- ##
==========================================
+ Coverage 72.94% 73.01% +0.07%
==========================================
Files 29 29
Lines 1785 1790 +5
Branches 380 383 +3
==========================================
+ Hits 1302 1307 +5
Misses 408 408
Partials 75 75
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
Fixes #7283
I believe the fix is as simple as allowing OPTIONS requests to pass through the proxy without authentication. Then the service behind the proxy should respond with 200 or 204.