fix(ASGI mounts): Prevent accidental scope overrides by mounted ASGI apps

[provinzkraut]

When mounting ASGI apps, there's no guarantee they won't overwrite some key in the scope that we rely on, e.g. scope["app"], which is what caused #3934.

To prevent this, I've implemented two things:

1. Do not store the Litestar instance under the generic app key, but the more specific litestar_app key. I've also added a Litestar.from_scope method, which can be used to safely access the current app from the sope
2. Added a new parameter copy_scope to the ASGI route handler, which, when set to True will copy the scope before calling into the mounted ASGI app. This should make things behave more as expected, since it truly give the called app its own environment without causing any side-effects. Since this change might break some things, I've left it with a default of None, which does not copy the scope, but will issue a warning if the mounted app modified it, enabling users to decide how to deal with that situation

Fixes #3934

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.34%. Comparing base (a814224) to head (98ac51d).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3945   +/-   ##
=======================================
  Coverage   98.34%   98.34%           
=======================================
  Files         347      347           
  Lines       15727    15743   +16     
  Branches     1738     1740    +2     
=======================================
+ Hits        15467    15483   +16     
  Misses        124      124           
  Partials      136      136           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[euri10]

dumb question maybe but what would happen if you mount a litestar app in a litestar app, won't you end up with the same issue you're fixing for other asgi apps ?

[provinzkraut]

dumb question maybe but what would happen if you mount a litestar app in a litestar app, won't you end up with the same issue you're fixing for other asgi apps ?

True, didn't think of that case as it's not something we really advertise and I can't immediately think of a use case.

copy_scope=True would fix this though. Not sure if we want to special-case app in the scope too much, since mounted apps might modify other things as well, which is why I added the copy option, so issues with this can be prevented outright.

If we want to handle this one case in particular, we could just "restore" the original app key after calling the mounted ASGI app?

[euri10]

The use case to is pretty much the same as this one: you mount something you have no control on ?

Realistically we'll have more Litestar users mounting FastAPI for the time being but you never know ;)

This was just a small remark, every asgi app is a squatter of the same namespace, but I'm all for squatts generally speaking so probably leaving this as is is a good option if ths copy_scope let the user solve the issue, it gives Litestar another edge other probably don't have.

[euri10]

excellent :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Documentation preview will be available shortly at https://litestar-org.github.io/litestar-docs-preview/3945