chalice icon indicating copy to clipboard operation
chalice copied to clipboard

accessing uri params for websockets api (question)

Open fullstackdev-online opened this issue 5 years ago • 6 comments

How to access uri query string parameters for websockets API with chalice?

E.g. my gateway uri has extra paramet(s) like wss://my-example-gateway.com/api/?id=some-id&param=value

In nodejs I'd access the id and param values using event.queryStringParameters like in the code below: exports.handler = async (event) => {
id = event.queryStringParameters.id, param = event.queryStringParameters.param, // ... do other stuff };

but in chalice on_ws_connect event argument (type WebsocketEvent) I only see

        self.domain_name = request_context['domainName']
        self.stage = request_context['stage']
        self.connection_id = request_context['connectionId']
        self.body = event_dict.get('body')

fullstackdev-online avatar Aug 03 '20 12:08 fullstackdev-online

Is something like this you were looking for?

@app.on_ws_connect()
def connect(event):
    params = event.to_dict()["queryStringParameters"]
    print('Params: %s' % params)

ivandjuricic avatar Aug 03 '20 15:08 ivandjuricic

Yeah, it looks like this isn't mapped right now. We currently use a single event class between all the websocket handlers (connect, message, disconnect), but the params such as queryString, headers, etc is only available on the connect handler. The on_ws_message handler has requestContext, body, isBase64Encoded whereas the on_ws_connect has:

headers, multiValueHeaders, queryStringParameters, multiValueQueryStringParameters, requestContext, isBase64Encoded.

While you can use @ivandjuricic's suggestion of event.to_dict() to get access to the underlying event dictionary, I think the long-term fix here should be to have separate event classes for connect, message, and disconnect. That way we can map the additional parameters into the connect handler.

This is technically a breaking change, but given that this is an experimental API I think now's a good time to update this.

Thoughts? /cc @stealthycoin

jamesls avatar Aug 05 '20 00:08 jamesls

this sounds good and fully makes sense and would be cleaner and more pythonic, though the workaround from @ivandjuricic is also easy to implement. So I'd vote for the enhancement, but it's definitely not a blocker.

fullstackdev-online avatar Aug 24 '20 17:08 fullstackdev-online

Hey guys any update on this ?

Ankushpandey-ti avatar May 19 '23 11:05 Ankushpandey-ti

Still no update?

robmoss2k avatar Feb 21 '24 11:02 robmoss2k