fix: add RootPathMiddleware for proper static file routing with root_…

[JartanFTW]

…path

When FastAPI/Starlette is deployed with root_path configured (e.g., behind a reverse proxy), static file requests could fail with 404 because Starlette's internal routing couldn't properly resolve paths for nested mounts.

This middleware normalizes request paths by prepending root_path when it's set but not included in the request path, ensuring StaticFiles and other nested mounts work correctly.

Fixes #538

All pytest cases pass. I also tested that this fix works via a docker-compose deployment on JartanFTW/sqladmin/tree/test/root-path-deployment

[JartanFTW]

For whatever reason this issue has disappeared even without the fix 😂 Not sure what's going on, or if this PR is necessary.

[aminalaee]

Can you please add a test to verify it's working as expected?

[JartanFTW]

Can you please add a test to verify it's working as expected?

From my original post:

All pytest cases pass. I also tested that this fix works via a docker-compose deployment on JartanFTW/sqladmin/tree/test/root-path-deployment

Can you please clarify what specific testing you want done?

[mmzeynalli]

@JartanFTW add a test which after redirecting to some page, check page url, and make sure that, root_path is in the URL

[mmzeynalli]

@JartanFTW any updates? Could you also add support for starlette 1.0 which was recently released? You just need to change pyproject.toml:

dependencies = [
  "starlette==0.49.3,<0.50.0; python_version == '3.9'",
  "starlette>=0.50; python_version >= '3.10'",
  "wtforms >=3.1, <3.2",
  "jinja2",
  "python-multipart",
  "sqlalchemy >= 2.0",
]

[JartanFTW]

It's on my todo list, just very busy at the moment and this is low priority for me. Apologies!
I'll try to get to it later today.

[JartanFTW]

Design decisions

1. Middleware moved from inner to outer app — The inner admin Starlette app receives root_path already appended with base_url by Starlette's Mount. This caused the middleware to prepend /api/v1/admin + /admin/... = double prefix. Moving it to the outer app means it sees the original root_path before any Mount processing.
2. Scoped to path_prefix — Since the middleware is on the user's app, we only rewrite paths starting with base_url to avoid touching their routes. The check uses the combined root_path + base_url prefix to determine whether rewriting is needed, which also correctly handles the edge case where root_path equals base_url. User routes already work fine with root_path because they don't go through nested Mount routing.
3. Starlette dependency pinned by Python version — starlette==0.49.3 for Python 3.9 (last supported version), starlette>=0.50 for 3.10+.

What the middleware does not cover

• WebSocket scope — Consistent with the rest of the library which is HTTP-only.
• Non-admin mounts — By design. Only admin routes need the fix because they use nested Starlette Mount routing. Top-levelroutes handle root_path natively.

Open question: Starlette pin for Python 3.9
The current pin is starlette==0.49.3 for Python 3.9, as requested by @mmzeynalli. Should this be ~=0.49.3 instead? That would allow patch releases (e.g., a hypothetical 0.49.4 security fix) while still staying within the 0.49.x line that supports Python 3.9. ==0.49.3 locks users out of any future patch.

[JartanFTW]

Ok now I'm actually done. Let me know how it looks

[mmzeynalli]

I know this is copied, but no need for type: ignore. I will remove others as well.

[mmzeynalli]

Open question: Starlette pin for Python 3.9 The current pin is starlette==0.49.3 for Python 3.9, as requested by @mmzeynalli. Should this be ~=0.49.3 instead? That would allow patch releases (e.g., a hypothetical 0.49.4 security fix) while still staying within the 0.49.x line that supports Python 3.9. ==0.49.3 locks users out of any future patch.

yes, totally agree. ~ us bettter than ==.

[mmzeynalli]

@JartanFTW would @MaximDementyev's solution work, instead of this much change?