Accessing request data in guards

[aranvir]

Hi, I was wondering if and how I can access the query data when from within a guard. The docs on guard only demonstrate how to use the user entity for role verification.

I already found out that I can access access the path parameters (e.g., /{project_id:int}) via connection.path_params and that query parameters can be accessed via connection.query_params. But it's not clear to me how to access the body of a request, so, the data object that is accessible from within a route handler function. I even checked the full connection.scope but could not find the data I sent within there.

Is that part of the request processed after the guard? I did try to execute connection.receive() within the guard and could find the data there but that will just cause the request to break - the route handler is no longer executed anymore and the client side freezes, waiting for a response.

[peterschutt]

What are you trying to do?

I.e., what do you need to achieve by accessing the request body in the guard?

[aranvir]

Right, sorry:

So in principle, users can have different roles depending on projects. So for one project user might have the rights to, e.g., add or remove users from that project, but they don't have those permissions for other projects.

For that specific example it would be sufficient to have a reference to the user and to the project - so connection.path_params and connection.user is fine. But I was curious if there was an option to also access the request body from a guard.

If not, I'll just put the "guard" within the function body.

[peterschutt]

Awaiting receive() is a bit low level and you'd be dealing with asgi messages if you receive anything at all. Also, if the body has already been accessed (perhaps in middleware, or other guards) then why you'd be left hanging on the receive() coroutine.

json() is probably what you want, but if you want the body parsed into a model type then you'd need to use either a dependency or interact with it in the handler.

[peterschutt]

Just to be clear though, you would almost never want to hit receive() in user code. If you consume those asgi messages, then we can't and so as far as the framework is concerned, those messages are lost and we'd not be able to parse the body of the request. So, not surprising that stuff blew up after that.

[aranvir]

I was not aware that the guard is getting the Request object - in the docs it says it's getting an ASGIConnection and that does not have the json() function. Then that's easy - and exactly what I was looking for.

I can make an issue (and prepare a PR later) to update that part of the docs so it's more clear.

[aranvir]

Yes, thanks! Calling receive() there seemed like a bad idea - but I was curious to find out what would happen :D

[peterschutt]

Yeh, we should document that better, feel free to open the issue and PRs for docs are always valued.

This is where the Request object is resolved, instantiated and passed to the guards:

litestar/litestar/routes/http.py

Lines 76 to 80 in 7bc6c34

	route_handler, parameter_model = self.route_handler_map[scope["method"]]
	request: Request[Any, Any, Any] = route_handler.resolve_request_class()(scope=scope, receive=receive, send=send)
	if route_handler.resolve_guards():
	await route_handler.authorize_connection(connection=request)

So the request type that you get in the guard is whatever is defined as the request_class on the app, or Request by default.

I think that it is typed as ASGIConnection on the guard callable due to the fact that guards are called for asgi and websocket handlers, in addition to http handlers. Maybe it would be better to type them as a union of those types instead of the base class to encourage narrowing within the guard for the use-case.