Multiple Admin Panels for the same fastapi App

[SwAt1563]

Checklist

• There are no similar issues or pull requests for this yet.

Is your feature related to a problem? Please describe.

I want to create multiple admin panels for one fastapi app.

Describe the solution you would like.

Adjust all the code to use dynamic "mount_name" instead of fixed names.

Describe alternatives you considered

No response

Additional context

class CustomAdmin(Admin):
    def __init__(
        self,
        app: Starlette,
        engine: ENGINE_TYPE | None = None,
        session_maker: sessionmaker | async_sessionmaker | None = None,
        base_url: str = "/admin",
        title: str = "Admin",
        logo_url: str | None = None,
        favicon_url: str | None = None,
        middlewares: Sequence[Middleware] | None = None,
        debug: bool = False,
        templates_dir: str = "templates",
        authentication_backend: AuthenticationBackend | None = None,
        mount_name: str = "admin",
    ) -> None:
        """
        Args:
            app: Starlette or FastAPI application.
            engine: SQLAlchemy engine instance.
            session_maker: SQLAlchemy sessionmaker instance.
            base_url: Base URL for Admin interface.
            title: Admin title.
            logo_url: URL of logo to be displayed instead of title.
            favicon_url: URL of favicon to be displayed.
        """

        super().__init__(
            app=app,
            engine=engine,
            session_maker=session_maker,
            base_url=base_url,
            title=title,
            logo_url=logo_url,
            favicon_url=favicon_url,
            templates_dir=templates_dir,
            middlewares=middlewares,
            authentication_backend=authentication_backend,
        )

        statics = StaticFiles(packages=["sqladmin"])

        async def http_exception(
            request: Request, exc: Exception
        ) -> Response | Awaitable[Response]:
            assert isinstance(exc, HTTPException)
            context = {
                "status_code": exc.status_code,
                "message": exc.detail,
            }
            return await self.templates.TemplateResponse(
                request, "sqladmin/error.html", context, status_code=exc.status_code
            )

        routes = [
            Mount("/statics", app=statics, name=f"{mount_name}_statics"),
            Route("/", endpoint=self.index, name=f"{mount_name}_index"),
            Route("/{identity}/list", endpoint=self.list, name=f"{mount_name}_list"),
            Route(
                "/{identity}/details/{pk:path}", endpoint=self.details, name=f"{mount_name}_details"
            ),
            Route(
                "/{identity}/delete",
                endpoint=self.delete,
                name=f"{mount_name}_delete",
                methods=["DELETE"],
            ),
            Route(
                "/{identity}/create",
                endpoint=self.create,
                name=f"{mount_name}_create",
                methods=["GET", "POST"],
            ),
            Route(
                "/{identity}/edit/{pk:path}",
                endpoint=self.edit,
                name=f"{mount_name}_edit",
                methods=["GET", "POST"],
            ),
            Route(
                "/{identity}/export/{export_type}", endpoint=self.export, name=f"{mount_name}_export"
            ),
            Route(
                "/{identity}/ajax/lookup", endpoint=self.ajax_lookup, name=f"{mount_name}_ajax_lookup"
            ),
            Route("/login", endpoint=self.login, name=f"{mount_name}_login", methods=["GET", "POST"]),
            Route("/logout", endpoint=self.logout, name=f"{mount_name}_logout", methods=["GET"]),
        ]

        self.admin.router.routes = routes
        self.admin.exception_handlers = {HTTPException: http_exception}
        self.admin.debug = debug
        self.app.mount(base_url, app=self.admin, name=mount_name)

[aminalaee]

I think it looks ok, but what is your use-case? Why do you need this in one app?

[simon1494]

Hi there! Why do you need multiple admins? Would you please explain a little more? Because maybe you could solve your problem in some other way with less overhead. I once built an app with 2 admins that ran well at first, but then it started to show some problems regarding url routing. I would not recommend this as it was extremely painfull to debbug. I ultimately discarted the option and followed other path.

[SwAt1563]

@aminalaee @simon1494 , In our use case, our company works as a consulting partner for clients. Therefore, our internal team requires a completely separate admin panel from the one provided to clients.

You might suggest implementing role-based permissions within a single panel, showing specific tables for clients and others for our team. While that’s a valid approach, having two entirely distinct admin panels gives us significantly more control and flexibility over the interface, data access, table visibility, and permission management. It ensures clearer boundaries, better customization, and a more secure and maintainable system architecture.

[simon1494]

Thanks, it's clearer now. Well, I think you could explore the option of having two admins in one app. In that case, I would suggets you to take a look at #738 first for a deeper understading of routing issues you may encounter. I'd love to give you more info on that, but to be honest I didn’t really dig into it, I ruled it out pretty early.

In the end, I ended up running two separate apps in a microservices architecture to have better individual control over each one. I know routing and auth might get a bit more complex this way (I use a dedicated service based on sqladmin as well, for auth which does all the heavy auth load and the other services just use its API), but hey, every option has its pros and cons — and I’d rather work with something I understand than fight the unknown, haha.

[MaximDementyev]

To implement this functionality, adding mount_name is not enough.

A few usage examples:

• I have several different large databases (adding all the tables in one application looks too massive), so I want to create two different Sqladmin applications and connect them within the same FastApi service.
• I have two completely identical databases (all tables are identical) and I want to manage them independently within the same FastApi.

Code example:

from sqlalchemy import Column, Integer, String, create_engine
from sqlalchemy.orm import declarative_base
from fastapi import FastAPI
from sqladmin import Admin, ModelView

Base = declarative_base()
engine1 = create_engine("sqlite:///example1.db",connect_args={"check_same_thread": False})
engine2 = create_engine("sqlite:///example2.db",connect_args={"check_same_thread": False})

class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    name = Column(String)

class UserAdmin(ModelView, model=User):
    column_list = [User.id, User.name]

Base.metadata.create_all(engine1)
Base.metadata.create_all(engine2)

app = FastAPI()
admin1 = Admin(app=app, engine=engine1, base_url='/admin/base1')
admin1.add_view(UserAdmin)

admin2 = Admin(app=app, engine=engine2, base_url='/admin/base2')
admin2.add_view(UserAdmin)

There are two problems to solve this problem:

1. SqlAdmin connects to the FastApi with a fixed name:

   sqladmin/sqladmin/application.py

   Line 449 in 5ec2360

   self.app.mount(base_url, app=self.admin, name="admin")

   
   Since query routing is calculated by name, no matter how many Admin applications we create, all links will lead to the first application created.
   Creating an additional name parameter is not enough, it is necessary to rewrite all url calculations, request.url_for("admin:list") is used everywhere.
2. The ModelView class uses the session_maker variable, which is a class variable. Therefore, when adding a second application, SqlAdmin session_maker will be overwritten. It turns out that no matter how many SqlAdmin applications we add, they will all work with the database added last.

To achieve the goal, you can do the following:

1. Using several different Sqladmin applications, by default, all links should work within the framework of the application in which the user is located. You can write a new method instead of request.url_for("admin:list"), which will find your current location and will search for the URL not using the full path of routers, but a relative one, such as local_url_for(request, "list")
2. Make the session_maker variable not a class variable but a class object variable