Skip to content

Little help with subscription middleware #246

Open
@jamesstidard

Description

@jamesstidard

Hi,

I've been playing around with graphql in this little test server. It's the server side implementation for a pictionary type game. I've managed to get queries, mutations and subscriptions working with python 3 style defs, asyncdefs and asyncgenerators.

I've used middleware on the http query/mutation requests without issue, however, getting middleware to play nice with the subscriptions has proven difficult for me and I was wondering if I could ask for some help.

I have been doing authentication for websocket connections by requiring a token to be provided along with any subscriptions that require auth. However, I'd like to move this to middleware and have the token handed up in connection params in the auth. This is the branch I stash the connection_params and pass them into the context.

In that same spot I add a auth middleware to handle authenticating websocket connections via those connection_params. Wrapping in a MiddlewareManager as suggested by @dfee in this issue.

The implantation of the authorize_ws middleware looks like this:

async def _authorize_ws_subscription(next, root, info, **args):
    token = info.context["connection_params"].get("authorization")
    await _authorize(token=token, info=info)

    async for msg in next(root, info, **args):
        yield msg


async def _authorize_ws_query_mutation(next, root, info, **args):
    token = info.context["connection_params"].get("authorization")
    await _authorize(token=token, info=info)

    result = next(root, info, **args)
    if inspect.isawaitable(result):
        return await result
    else:
        return result


def authorize_ws(next, root, info, **args):
    if info.operation.operation == 'subscription':
        return _authorize_ws_subscription(next, root, info, **args)
    else:
        return _authorize_ws_query_mutation(next, root, info, **args

However, this info.operation.operation == 'subscription' check does not appear to be sufficient for determining how to handle the request and results in my subscription websocket spitting out stringified rx objects for values e.g.:

{
  "id": "6",
  "type": "start",
  "payload": {
    "variables": {
      "uuid": "<rx.core.anonymousobservable.AnonymousObservable object at 0x106d8c7f0>"
    },
    "extensions": {},
    "operationName": "roomDeleted",
    "query": "subscription roomDeleted($uuid: String!) {\n  roomDeleted(uuids: [$uuid]) {\n    uuid\n    __typename\n  }\n}\n"
  }
}

What it appears to be is that not all subscription operations expect a asyncgen as some subscription calls are for attr_resolve and not the base subscription itself. Anyway, putting in this hacky line fixes it... (where my base Subscription graphene.ObjectType is named Subscription). Though of course this then skips authentication for those calls.

def authorize_ws(next, root, info, **args):
    if info.operation.operation == 'subscription':
        if not str(next).startswith('Subscription.'):
            return next(root, info, **args)
        return _authorize_ws_subscription(next, root, info, **args)
    else:
        return _authorize_ws_query_mutation(next, root, info, **args)

Would appreciate any pointers. Sorry for posting links to a codebase instead of a smaller snippet, I'm not sure however where in the chain I'm doing things incorrectly (as maybe it's my resolvers that are written incorrectly for the middleware and not vice-versa).

Here's a few anchors around the codebase:

Query: dixtionary.model.query.Query
Mutation: dixtionary.model.mutations.Mutation
Subscription: dixtionary.model.subscriptions.Subscription
Middleware: dixtionary.middleware.authentication.authorize_ws
WsLibSubscriptionServer Monkey-patching: dixtionary.extensions.graphql

Thanks to anyone that indulges such a long post, and Sorry.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions