Websockets: allow setting connection userdata in accept-handler

[MichaelSB]

It would be useful, if one could return userdata in the accept-handler stage of websockets. Currently the accept-handler returns only bool. I suggest something returning std::pair<bool, void*>.
My usecase would be delegation of websocket-messages to specific instances of classes, depending on the WS-Url

CROW_ROUTE(app, "ws/<string>).websocket()
    .onaccept([](const crow::request& req) {
        auto id = get_id_from(req); // some function to get the string in the url
        auto client = get_client_from_id(id);
        
        return client != nullptr;
    })
    .onmessage([](crow::websocket::connection& conn, const std::string message, bool is_binary) {
        // here I have no way to get the client?
    });

returning userdata in a variant of onaccept would enable me to do

CROW_ROUTE(app, "ws/<string>).websocket()
    .onaccept_with_userdata([](const crow::request& req) {
        auto id = get_id_from(req); // some function to get the string in the url
        auto client = get_client_from_id(id);
        
        return { client != nullptr, client };
    })
    .onmessage([](crow::websocket::connection& conn, const std::string message, bool is_binary) {
        auto client = static_cast<MyClient*>(conn.userdata());
        client->handle_message(message, is_binary);
    });

Is there currently any other way doing what I want to do?

[The-EDev]

Normally id and client would be variables outside the route, onaccept would just set them and onmessage would assume that they exist (since returning false from onaccept closes the connection). I believe the websocket example does this already.

[MichaelSB]

How would this work with multiple clients connecting? onmessage does not know which client-instance I am referring to then. https://github.com/CrowCpp/Crow/blob/master/examples/websocket/example_ws.cpp just keeps a collection of connections and uses them in onmessage. That does not work for me.
I have an unordered_set<std::string, MyClient*> with different classes implementing an API to consume and produce WS-Messages. What they do exactly with the data presented depends on some actions the user did in the webapp. One user could have many of these MyClient* active in the backend. At some point the webapp needs to open a websocket associated with one of these MyClient*. So in the end a user has N MyClient* in the backend with N open websockets. Each websocket should be hardwired with one of the MyClient-instances. The idea is now to lookup the requested client in the unordered_map in onaccept and pass it down to onmessage and friends. I don't see any way besides using userdata, which is already part of websocket::connection. An option would be to send the id in the first message and associate the client to the connection via userdata in onmessage. But this seems a bit awkward to me. It's either using a generic url and having to accept any request until the first message arrives or using the -Url and having to send the same id in a message after accept/open again.

[The-EDev]

What about just adding userdata to the arguments of the accept handler, wouldn't this solve the issue without changing the return statement?

[MichaelSB]

Yes,adding a void** argument to the accept-handler and setting it to the connection's userdata-adress before calling it, would work as well. I don't care much, if I can set the data by ref or by return :)

[MichaelSB]

FWIW, I tried both versions. Adding a new void**-argument to the accept-handler works as expected. So does adding a new handler with the pair in the return. Adding the argument seems a bit more intrusive to me, because it changes the existing onaccept. The patch is a bit smaller though. As both versions work, I have no preference. I could provide patches for both versions, if you like.

[The-EDev]

@MichaelSB Thanks, I only made sure that the code compiles so I'm glad you fully tested it. Feel free to open a PR implementing the argument (existing onaccept functions would only need to add void** without any name) or let me know if you'd like me to.
In the future it might be worth revisiting this and using templates to make it similar to CROW_ROUTE (in the sense that you can have either a function with req or req and void**)

[MichaelSB]

Yeah, templating to accept versions with/without void** would be best. I'll try doing this.