-2

I want to submit an HTML form to a server which accepts the form data in the queryString along with Authorization header. The server then sends back a HTML document after performing some computations on the data and the Authorization header.

Restrictions

  1. I cannot use JavaScript features like AJAX or fetch since the form submission gets a HTML response which needs to be opened on the browser.
  2. The form also needs to be of the method GET for internal reasons.

Response

The response received is a HTML document which has JavaScript in it which has sessionStorage.setItem('data', 'value') in it, which is scoped to the origin. The form exists in the parent.example.com origin, whrereas the received HTML document is in child.example.com origin. So, we Must go to the child.example.com page like a HTML form redirection.

deekeh
  • 675
  • 1
  • 6
  • 21
  • 1
    You can set the `Authorization Header` by using an API platform like [Postman](https://www.postman.com/) and input your value as `queryString` – Jordy Apr 17 '23 at 07:50
  • Does queryString not have a max-length of 2048 characters? @Jordy – deekeh Apr 17 '23 at 07:52
  • 2
    @Jordy — Expecting users of a website to leave the website and use an API testing tool to access the data instead of a form doesn't seem reasonable. – Quentin Apr 17 '23 at 07:54
  • 1
    @deekeh — Why does that matter here? – Quentin Apr 17 '23 at 07:55
  • @deekeh I think no limitation on queryString characters' length, just try it if there aren't any errors. – Jordy Apr 17 '23 at 07:58
  • @Quentin We have a very large Authorization header (of more than 4000 characters), and putting it into the queryString might now work because of the length restriction. – deekeh Apr 17 '23 at 07:58
  • 3
    @deekeh — The Authorization Header is separate to the query string. That's why it is a *header* and not part of the URL. – Quentin Apr 17 '23 at 07:59
  • @Jordy we also do not want to copy the HTMl content and just do document.open() and dump the HTML in it, because it contains a code to set sessionstorage in it, which is scoped to the origin. – deekeh Apr 17 '23 at 08:00
  • @deekeh Opening the document obtained through a `fetch` (what you are referring to with "HTML content") will be problematic because its origin will be distinct and it won't be able to talk (scripted) to your site origin. Otherwise everybody'd be doing it and circumventing an entire layer of security protections in the browser. As you yourself asked for, the _correct_ and the only good way to accomplish this is to rely on the good old form submission and have the server send status and headers as per @Quentin's answer. If you don't control the server, install a proxy between it and the client. – Armen Michaeli Apr 17 '23 at 08:01
  • 1
    It's really sounding like this HTML resource was never meant to be loaded client-side from a 3rd-party site. – Phil Apr 17 '23 at 08:10
  • @Jordy there is no limitation on length in Postman but browsers would have limitations on how long a URL can be. – deekeh Apr 17 '23 at 08:51
  • Is that bad or good news? – Jordy Apr 17 '23 at 08:52
  • @ArmenMichaeli I can send all the data via form, but I just want a way to send the Authorization header also, along with the form. – deekeh Apr 17 '23 at 08:53
  • Bad news, limitations would mean that I cannot send the authorization header via queryString, as you suggested initially. The header is like 4400 characters long. – deekeh Apr 17 '23 at 08:53
  • Is it possible for the form to send [Form-Data](https://learning.postman.com/docs/sending-requests/requests/#form-data) instead of `queryString`? – Jordy Apr 17 '23 at 08:56
  • Is form-data supported in a GET call? – deekeh Apr 17 '23 at 08:57
  • Yes, it support GET – Jordy Apr 17 '23 at 08:57
  • A post suggested otherwise. https://specs.openstack.org/openstack/api-wg/guidelines/http/methods.html#:~:text=HTTP%20request%20bodies%20are%20theoretically,TRACE%2C%20OPTIONS%20and%20HEAD%20methods. – deekeh Apr 17 '23 at 09:03
  • 1
    @deekeh Update your question and state clearly what is it you are trying to do once you get response from the server. Do you control the server? It's completely inconsequential how long query strings can get and whether you can send your header in the URL. The fact you have not accepted Quentin's answer tells me you're not explaining your use case very well. – Armen Michaeli Apr 17 '23 at 09:04
  • 1
    @deekeh Where does your linked post suggest otherwise, exactly? `GET` is the _default_ method used for submitting HTML forms and the form data is encoded using `application/application/x-www-form-urlencoded` media type and submitted with the URL specified by the form's `action` attribute. So yes, it's perfectly valid to submit a form with the `GET` HTTP method. It is the _server_, however, that negotiates authorization and will have to reply with e.g. `401` status code and specify `WWW-Authenticate` in order for the browser to attempt further authorization as directed by the server. – Armen Michaeli Apr 17 '23 at 09:11
  • @ArmenMichaeli I have addedsome updates to the post. The linked post mentions > *HTTP request bodies are theoretically allowed for all methods except TRACE, however they are not commonly used except in PUT, POST and PATCH. Because of this, they may not be supported properly by some client frameworks, and you should not allow request bodies for GET, DELETE, TRACE, OPTIONS and HEAD methods.* – deekeh Apr 17 '23 at 09:24
  • 1
    A request body can be had (used for form data with `POST`) for `POST` and some other methods, but not `GET` and some others again, correct. This isn't controversial or new knowledge. What does anything of it have to do with your question though? You're submitting the form with GET and the data go into the URL, as they should. Anyway, it's pretty clear hacking this through scripting won't work -- the origin of a page loaded from a response through scripting, won't be your site so you have no choice but alter server headers or install a proxy. Do you understand what I mean? – Armen Michaeli Apr 17 '23 at 09:51

1 Answers1

3

There is no way for client-side code to do this.

The closest you could come would be to have the server respond to the request with a 401 Unauthorized status and a WWW-Authenticate: Basic header which would cause the browser to prompt the user for credentials with its native UI and, after the user enters them, repeat the request with an added Authorization using the format of Basic Auth.

As Phil mentions in the comments, it does sound like the URL you want to request simply isn't designed to be navigated to directly by a browser.

Rather than trying to work around that, you would probably be better off changing the authentication system to something else (such as cookies which are set in response to a submission from a traditional login form)

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • Thanks for the answer! But set-cookie is also not viable for our case, since my header is more than 4400 characters long; and cookie has a limitation of 4096 characters. – deekeh Apr 17 '23 at 09:19
  • 4
    Then perhaps you need a less verbose authentication system. – Quentin Apr 17 '23 at 09:21