starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 09:16:03 +03:00

[GH-ISSUE #933] Support header manipulation and pre-request scripting while establishing websocket connection #331

New issue

Closed

opened 2026-03-16 14:44:49 +03:00 by kerem · 10 comments

kerem commented

2026-03-16 14:44:49 +03:00

Owner

Originally created by @rvit34 on GitHub (Jun 11, 2020).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/933

Is your feature request related to a problem? Please describe.
It would be nice to have an ability to add custom headers (host, api-key, etc.) to pass auth check during establishing websocket connection. Also I need to sign my request, so some pre-request script would be useful as well. Currently your tool does not provide such abilities.

Describe the solution you'd like
The Solution is similar you already have for regular http requests.

Originally created by @rvit34 on GitHub (Jun 11, 2020). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/933 **Is your feature request related to a problem? Please describe.** It would be nice to have an ability to add custom headers (host, api-key, etc.) to pass auth check during establishing websocket connection. Also I need to sign my request, so some pre-request script would be useful as well. Currently your tool does not provide such abilities. **Describe the solution you'd like** The Solution is similar you already have for regular http requests.

kerem

2026-03-16 14:44:49 +03:00

closed this issue
added the
feature

hacktoberfest
labels

kerem commented

2026-03-16 14:45:05 +03:00

Author

Owner

@LeoMartinDev commented on GitHub (Oct 3, 2020):

I'll look into it

@LeoMartinDev commented on GitHub (Oct 3, 2020): I'll look into it

kerem commented

2026-03-16 14:45:10 +03:00

Author

Owner

@liyasthomas commented on GitHub (Oct 3, 2020):

@LeoMartinDev great. Let me know if you need any help.

@liyasthomas commented on GitHub (Oct 3, 2020): @LeoMartinDev great. Let me know if you need any help.

kerem commented

2026-03-16 14:45:15 +03:00

Author

Owner

@LeoMartinDev commented on GitHub (Oct 3, 2020):

@LeoMartinDev great. Let me know if you need any help.

Thanks ! IMO we should split this into several PR to minimize diff.
I'm going to add the Headers section in a first PR

@LeoMartinDev commented on GitHub (Oct 3, 2020): > @LeoMartinDev great. Let me know if you need any help. Thanks ! IMO we should split this into several PR to minimize diff. I'm going to add the Headers section in a first PR

kerem commented

2026-03-16 14:45:20 +03:00

Author

Owner

@LeoMartinDev commented on GitHub (Oct 4, 2020):

That's much bigger than what I thought. I had to make a reusable Parameters Headers component & corresponding entries in the store (new websocket state).

@LeoMartinDev commented on GitHub (Oct 4, 2020): That's much bigger than what I thought. I had to make a reusable Parameters Headers component & corresponding entries in the store (new websocket state).

kerem commented

2026-03-16 14:45:25 +03:00

Author

Owner

@LeoMartinDev commented on GitHub (Oct 4, 2020):

Hmm I don't know if this feature is really useful as Websocket API allows only one header : Sec-WebSocket-Protocol https://stackoverflow.com/questions/39853185/custom-headers-for-websocket-js

@LeoMartinDev commented on GitHub (Oct 4, 2020): Hmm I don't know if this feature is really useful as Websocket API allows only one header : `Sec-WebSocket-Protocol` https://stackoverflow.com/questions/39853185/custom-headers-for-websocket-js

kerem commented

2026-03-16 14:45:30 +03:00

Author

Owner

@liyasthomas commented on GitHub (Oct 6, 2020):

@rvit34 can you produce an example of making use of custom headers in WebSocket

@liyasthomas commented on GitHub (Oct 6, 2020): @rvit34 can you produce an example of making use of custom headers in WebSocket

kerem commented

2026-03-16 14:45:36 +03:00

Author

Owner

@jreffitt commented on GitHub (Nov 5, 2020):

So what about the 'origin' header? Seems important for security and it looked like I could use this tool to test a socket connection. This doesn't work and without being able to set the headers in the test it will never work... I am able to use node's SocketIO library to do this and my web ui example works.

@jreffitt commented on GitHub (Nov 5, 2020): So what about the 'origin' header? Seems important for security and it looked like I could use this tool to test a socket connection. This doesn't work and without being able to set the headers in the test it will never work... I am able to use node's SocketIO library to do this and my web ui example works.

kerem commented

2026-03-16 14:45:41 +03:00

Author

Owner

@liyasthomas commented on GitHub (Nov 5, 2020):

As per this:

The WebSocket standard defines an Origin header field, which web browsers set to the URL that originates a WebSocket request. This can be used to differentiate between WebSocket connections from different hosts, or between those made from a browser and some other kind of network client. However, remember that the Origin header is essentially advisory: non-browser clients can easily set the Origin header to any value, and thus “pretend” to be a browser.

And per this:

If we could forge the origin of requests in JavaScript, the same origin policy wouldn't be very good at keeping us safe. It exists solely to protect us from this and other potential attack vectors.

So basically the WebSocket protocol doesn’t handle authorization or authentication. Practically, this means that a WebSocket opened from a page behind auth doesn’t “automatically” receive any sort of auth. Thus many servers use Origin header verification to avoid abusing WebSocket endpoints. I guess that makes sense, it protects users from bad js even though it doesn't protect servers from bad clients.

So it's better not to implement this where there could be a chance to forge origin header and thus invite chances for abusing WebSocket endpoints.

As per this:

A less hacky solution would require the use of a proxy which can re-write your headers for you on-the-fly. Consider install nginx on your system, and then proxing the request to target IP keeping everything the same except for the Origin header.

Also: https://github.com/hoppscotch/hoppscotch/issues/1331#issuecomment-728881676

@liyasthomas commented on GitHub (Nov 5, 2020): As per [this](https://devcenter.heroku.com/articles/websocket-security#:~:text=The%20WebSocket%20standard%20defines%20an,other%20kind%20of%20network%20client.): > The WebSocket standard defines an Origin header field, which web browsers set to the URL that originates a WebSocket request. This can be used to differentiate between WebSocket connections from different hosts, or between those made from a browser and some other kind of network client. However, remember that the Origin header is essentially advisory: non-browser clients can easily set the Origin header to any value, and thus “pretend” to be a browser. And per [this](https://stackoverflow.com/a/30144314): > If we could forge the origin of requests in JavaScript, the same origin policy wouldn't be very good at keeping us safe. It exists solely to protect us from this and other potential attack vectors. So basically the WebSocket protocol doesn’t handle authorization or authentication. Practically, this means that a WebSocket opened from a page behind auth doesn’t “automatically” receive any sort of auth. Thus many servers use `Origin` header verification to avoid abusing WebSocket endpoints. I guess that makes sense, it protects users from bad js even though it doesn't protect servers from bad clients. So it's better not to implement this where there could be a chance to forge `origin` header and thus invite chances for abusing WebSocket endpoints. As per [this](https://stackoverflow.com/a/30144315): > A less hacky solution would require the use of a proxy which can re-write your headers for you on-the-fly. Consider install nginx on your system, and then proxing the request to target IP keeping everything the same except for the Origin header. Also: https://github.com/hoppscotch/hoppscotch/issues/1331#issuecomment-728881676

kerem commented

2026-03-16 14:45:46 +03:00

Author

Owner

@jugglingjsons commented on GitHub (Dec 1, 2020):

I would like to drop my 3 cents on that.
With modern cloud environments ( I am talking about AWS api gateway specifically here) there's exactly the kind of magic necessary happening to pass the headers in.
Besides Authorization is not the only thing the headers can be used for. Imho there should be a way to define custom headers on connection. The other requests don't really need it as it's more of the responsibility of the app to retain the connection context somehow, but connection definitely needs them.

Taking a look at other clients, especially terminal ones, like wscat for example, it's perfectly fine to use custom headers in connect - they treat it as http handshake.

whatwg/websockets#16 Here's another thread where this discussion is ablaze.

@jugglingjsons commented on GitHub (Dec 1, 2020): I would like to drop my 3 cents on that. With modern cloud environments ( I am talking about AWS api gateway specifically here) there's exactly the kind of magic necessary happening to pass the headers in. Besides Authorization is not the only thing the headers can be used for. Imho there should be a way to define custom headers on connection. The other requests don't really need it as it's more of the responsibility of the app to retain the connection context somehow, but connection definitely needs them. Taking a look at other clients, especially terminal ones, like wscat for example, it's perfectly fine to use custom headers in connect - they treat it as http handshake. whatwg/websockets#16 Here's another thread where this discussion is ablaze.

kerem commented

2026-03-16 14:45:51 +03:00

Author

Owner

@tayler-king commented on GitHub (Feb 28, 2023):

I think pre-request scripts for WebSocket connections would still be a good idea. A few ideas on this:

Adding generated parameters to the WebSocket connection url
Changing the protocol header programmatically
Establishing variables that can be used in socket messages prior to the connection opening
Maybe the functionality to queue messages that should be sent once a connection has been established?

In my particular instance, I have a WebSocket server that requires authentication to establish the connection. A refresh token is used to generate an authentication token which is passed to the WebSocket server during the upgrade request.

It would be nice to be able to fetch a new authentication token as appropriate - they're short lived and invalidate the refresh token used for generation, meaning it's quite inconvenient to manually generate new tokens each time.

@tayler-king commented on GitHub (Feb 28, 2023): I think pre-request scripts for WebSocket connections would still be a good idea. A few ideas on this: - Adding generated parameters to the WebSocket connection url - Changing the protocol header programmatically - Establishing variables that can be used in socket messages prior to the connection opening - _Maybe the functionality to queue messages that should be sent once a connection has been established?_ In my particular instance, I have a WebSocket server that requires authentication to establish the connection. A refresh token is used to generate an authentication token which is passed to the WebSocket server during the upgrade request. It would be nice to be able to fetch a new authentication token as appropriate - they're short lived and invalidate the refresh token used for generation, meaning it's quite inconvenient to manually generate new tokens each time.

kerem referenced this issue

2026-03-17 00:15:24 +03:00

[PR #331] [CLOSED] Make primary and secondary navs easier to distinguish #2564