Issue with routes.admin change to be '/'

[TatisLois]

Bug Report

In the file payload.config.ts changing the property routes.admin to be the base route of the server / causes the application to break and only show a blank screen.

Steps to Reproduce

After a fresh install of we

1. npx create-payload-app@latest -> Fresh Install
2. Modify payload.config.ts to include

  routes: {
    admin: "/",
  },

4. Modify server.ts to not redirect '/' to '/admin'
5. Start server

Other Details

The issue was first brought up on discord, at -> https://discord.com/channels/967097582721572934/1047370284975530056/1047525493391507466

With a proposed solution from @JarrodMFlesch

[JarrodMFlesch]

To preface, admin.routes affect both the backend and the frontend.

The Frontend (files in src/admin)

Changes are pretty simple, you search for routes.admin and in any place where routes.admin precedes another slash, you will need to sanitize it by removing the trailing slash, a helper function like this would work well:

function removeTrailingSlash(str) {
  return str.endsWith('/') ? str.slice(0, -1) : str;
}

In the /src/admin/components/Routes.tsx file

• root Route path needs to be sanitized
• occurrences of match.url need to be sanitized

The Backend (files in /src/* but not in /src/admin)

This side is a bit trickier, in /src/init.ts, routes get mounted currently in the following order:

• admin routes routes.admin i.e. /admin
• api routes routes.api i.e. /api
  • collection routes, prepended with routes.api value
  • globals routes, prepended with routes.api value
  • access, prepended with routes.api value
  • graphQL, prepended with routes.api value
  • graphql-playground, prepended with routes.api value
• static routes (directory)

If we allow routes.admin or routes.api to be /, then the ordering above is critical. In its current state when admin is set to / it mounts to express before the api routes, so all routes are captured by the admin route handler. If we rearrange the routes, so admin mounts after api, that would not work for people who set routes.api to /, it would result in no admin panel, but a working api.

We could group them better in this file, and then dynamically attach them in a specific order if either routes.admin or routes.api were set to /.

I am not exactly sure how we want to handle this part. @jmikrut any thoughts here?

[jmikrut]

@JarrodMFlesch I think your statements above are accurate. A user would always have to scope one or the other to avoid conflicts, but technically we could determine that in code and mount in the proper order one way or another.

This is a feature request rather than a bug though—as we have not intended the admin route to be able to mount to the root up until this point. So I'm going to convert this to a Discussion and mark it as a planned roadmap item.

Let's make it happen!

[gregwhitworth]

@jmikrut @JarrodMFlesch Before I upvote this, is this the same as asking for admin to be customized to a different term; for example settings or account?

[jmikrut]

You can already do that! Use the config property routes.admin 👍

[dsod]

Hey,
We have the same use-case as well, where we want the admin UI served on the root path /. While it's possible for us to solve this in a LB/reverse proxy layer I think there are value to be added to Payload here. I think we could solve this use-case, as well as fixing some other routing "gotchas" at the same time. I can work on this if the proposed solution below sounds good.

Issue summary
Order of routes added to Express matters. If a less "specific" route (especially if it includes parameters or wildcards) is added before a more specific route is, the less specific route will match on requests and the more specific route will never be matched.

As explained above, routes in Payload are currently registered in a specific order. At the same time, Payload allows for configuration of internal payload "base routes" as well as registering custom routes and serving of static files. This can lead to conflicts between Payloads internal routes, as well as conflicts between the internal routes and custom routes.

Solution & Challenges
Basically, routes needs to be sorted before added to Express. The sorting would happen separately on:

• Root routes added to the Express app object (including express.Router()'s)
• Within each router
  By sorting the routes within each "context" there would no longer be conflicts between internal routes or custom routes.

After sorting the routes they would need to be registered with the proper method (i.e. initAuth, initCollectionsHTTP, initStatic, etc). The hard part here is that we need to think about performance at the same time as the order. We don't want to call a function each time we register a route but rather pass in an array of routes as much as possible. Refactoring to some of the init{RouteType} methods could be needed.

This would look something like:

1. Gather all routes and categorize them by "Route type" (i.e. api, custom, admin, static, and so on)
2. Sort the routes for by path and specificity, where static routes are more specific than dynamic routes, dynamic routes more specific than regex routes, and so on
3. Loop through the sorted routes. Each time the Route type of the current item (i) is different from the Route type of the previous item (i - 1), we commit all the previous items (for performance)

Here is an example I wrote that weights different types of routes according to it's specificity (not a perfect solution, but working I think):
Typescript Playground - Route specificity sorting example

Of course, if a decision to move to Next is made, then perhaps this change is no longer relevant. Let me know what you think!

[IRediTOTO]

Why can't we solve this problem? I just want to access Payloadcms at my domain dashboard.abc.com not dashboard.abc.com/amin :\