Learning about the idea of the HTTP self-post
You might ask, as I did when I read about this today, why website B doesn't make its own POST request to website A's endpoint instead of relaying its block of information through your browser. One reason is that website B may not be able to communicate directly with website A. Website B might be your corporate single sign on portal while website A is an internal web server inside your group's internal networks.
Another reason is that your browser may have to go back to website A anyway and coordinate with the information that website B is delivering to A. Again, consider SSO. Your browser has to return to website A to use it (and perhaps to be authorized), but website A needs to have the information from website B before it can do anything with you. It's simpler and more reliable to bolt these two things together, so that either you wind up on website A with it having all of the information necessary to move forward (in theory) or you go nowhere.
(In this scenario you visited website A as an unidentified and unauthenticated person and it sent you to website B to get identified. Your browser is the only thing guaranteed to be able to reach both websites, because if you can't reach one or the other nothing works.)
Hopefully I will never need to build a web system that uses HTTP self-post(ing), but at least now my ideas of how things can be done with HTTP have been expanded a bit. And if I do build such a system, I will have to carefully consider how to shield it from CSRF, since the two are so close to each other.
Comments on this page:Written on 15 April 2021.