-
Notifications
You must be signed in to change notification settings - Fork 4
Description
When the application starts getting some real-world use, I can imagine there are going to be security concerns with not being able to customize the URL at which admin panel is accessed.
In the first few days of development, it was designed that these endpoints were customizable when configuring the primary backroad() object. However, as things grew I ran into some issues where I was having trouble relaying to the client-side pieces of the application what that current dynamic endpoint was.
For example, I was having issues with routing in the admin React application, because I didn't have a way to get that specified /admin base endpoint configured on the server-side of things by the developer creating the backroad() object. So this inevitably was changed and the routes became hard-coded to /admin and /install.
However, since that point, other similar issues kept creeping up, which suggested some things needed to be changed about the architecture of things. The general issue was passing dynamically created things from the developer using the framework (like content types, general configuration settings, etc) down to client-side applications.
To eventually solve this general architectural issue, I ended up turning to server-side rendering. The index.html file is now rendered from a Handlebars template before being served to the client, where a configuration object with everything the client needs is inserted in a big JSON object printed right there in the <head>.
... So that was a longe explanation to say we can now easily make /admin and /install endpoints customizable by the developer. All we need to do is add them to server-side rendered backroad JSON object that gets rendered in the client's HTML file. That can then replace any hard-coded instances of admin within the client-side application.