-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Form submission warning does not address redirects #31
Comments
I don't think the current text would prevent a form submission to the HTTP endpoint to begin with. AFAIR, any warning or enforcement is wrapped up in "The user agent MAY do whatever it feels like here instead of just returning But it's been a long time since I looked at this. Are we more explicit about the algorithm somewhere? |
The problem is with the text at https://w3c.github.io/webappsec-mixed-content/#requirements-forms (that MIX2 doesn't seem to meaningfully alter, but that's #28). It allows for warning or even blocking, but ignores the redirect problem entirely. |
Got it, thanks! Yes, that text only handles explicitly mixed content (e.g. @carlosjoan91 and @estark37 are the right people to chat with about the UX considerations from Chromium's side. |
That would allow a page to hide the user-facing warning quite easily while not solving the problem. (And potentially create other problems depending on how they go about creating this redirect.) |
In Chromium the current UI doesn't degrade on redirects, but I think that's more due to implementation issues (i.e. having to actually trigger a navigation to the target URL before form submission to detect redirects) rather than by design. I can add a step explaining the UA may show a warning if a redirect to an HTTP URL is found while submitting a form from an HTTPS URL if other implementers are interested in something similar. |
As MIX2 replaces MIX I don't see a real need to maintain the former personally. I'm not sure if Firefox is interested in implementing such a warning, but it does seem to me that any implementation that does not warn upon such a redirect is incomplete and has UI that can be easily circumvented. |
As far as I can tell the current text would not prevent or require a dialog for a POST to https://same-origin.example/endpoint to 307/308 redirect to http://elsewhere.example/actual-endpoint.
The text was updated successfully, but these errors were encountered: