Replies: 1 comment
-
Just stumbled upon this and my first thought is to use a lightweight “phone home” approach that injects the response directly into the markup. For this, you would supply a self-contained JavaScript file that users include in their HTML and that makes an AJAX request to a controller action provided by the plugin, injecting the HTML response into the markup. This is the pattern that Sprig uses (powered by htmx) and that has proven very effective. Authentication would be handled via cookies, which is trivial for statically cached sites that have a login form. Headless sites could in theory work with cookies too, however browsers impose constraints on cross-domain cookies and AJAX requests which would need to be considered. Once a user is authenticated, the controller action endpoint would return the exact markup, including the HTML and CSS, that is required to display the styled admin bar. This would happen with a small delay, as the request kicks off on page load and happens concurrently, without render blocking the rest of page, so should come into view with a smooth animation that does not result in any layout shift. When unauthenticated, the endpoint would return an empty response, in which case nothing changes on the page. Happy to hear your thoughts and help brainstorm further. |
Beta Was this translation helpful? Give feedback.
-
On projects that use static caching, like FastCGI or Blitz, Admin Bar relies on you having a login session on the same domain to authenticate the right user and display the bar on the front-end. This setup is a bit clunky and it would be nice to come up with a more element implementation.
While consider this, I’ve been trying to find a solution to allow for Admin Bar to appear on the front-end of headless projects, where it can't be guaranteed that the front-end shares any common domain or server properties with the Craft CMS install. Some solutions might include creating the front-end Admin Bar as a standalone npm package and doing some sort of authentication with the back-end, but I'm struggling to find an approach that is secure and flexible across JavaScript frameworks that are commonly used for headless projects.
The solution doesn’t have to be the same for both of these issues, but I think solving them both is an important part to keeping this plugin relevant. I feel like I don't have the experience to think through the steps involved in solving these issues, so I'd greatly appreciate some suggestions!
Beta Was this translation helpful? Give feedback.
All reactions