Skip to content
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

Possibility to mirror Sec-WebSocket-Protocols #980

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

andrew-guz
Copy link

Hello.

We are using Sec-WebSocket-Protocols to send important data, that is not constant. So we can't predict subprotocol on server side.
From the other hand, we have to send something back, otherwise Browsers will not work correctly.

So, we suggest the next solution: add a possibility to return exactly the same subprotocol that was received.

gittiver
gittiver previously approved these changes Jan 9, 2025
@gittiver
Copy link
Member

gittiver commented Jan 9, 2025

We are using Sec-WebSocket-Protocols to send important data, that is not constant. So we can't predict subprotocol on server side. From the other hand, we have to send something back, otherwise Browsers will not work correctly.

We can add this to Crow, but with this few informations it sounds like a strange design. You should think about if it maybe opens an attack vector or something like this.

Comment on lines 3207 to 3208
static websocket::connection* connection = nullptr;
static bool connected{false};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this shouldn't be static

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@andrew-guz
Copy link
Author

andrew-guz commented Jan 9, 2025

We are using Sec-WebSocket-Protocols to send important data, that is not constant. So we can't predict subprotocol on server side. From the other hand, we have to send something back, otherwise Browsers will not work correctly.

We can add this to Crow, but with this few informations it sounds like a strange design. You should think about if it maybe opens an attack vector or something like this.

We are using Sec-WebSocket-Protocols to send some information about client. And this data will be different for different clients. We want to get this info during onAccept, and reject, depending on this information if needed.
Since we have to send something back (https://datatracker.ietf.org/doc/html/rfc6455#section-11.3.4) this was the easiest solution for us.

@andrew-guz andrew-guz requested a review from gittiver January 9, 2025 10:59
@@ -498,13 +498,20 @@ namespace crow // NOTE: Already documented in "crow/app.h"
return *this;
}

self_t& mirrorprotocols()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have expected:

         self_t& mirrorprotocols(bool mirror_protocols=true)
         {
             mirror_protocols_ = mirror_protocols;
             return *this;
         }

to make clear that something will be set?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change this, for sure. But not clearly understand, how this method can be called somewhere to disable mirror functionality, because we're usually doing like this:

    CROW_WEBSOCKET_ROUTE(app, "/PATH")
      .mirrorprotocols()
      .onaccept(...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

c.send(asio::buffer(http_message));

c.receive(asio::buffer(buf, 2048));
std::this_thread::sleep_for(std::chrono::milliseconds(5));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this there only to keep the connection open?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As in many tests before...

@andrew-guz andrew-guz requested a review from gittiver January 10, 2025 09:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants