Support

Admin Tools

#36362 Password-protect Administrator blocks component on front-end

Posted in ‘Admin Tools for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Admin Tools version
n/a

Latest post by on Wednesday, 09 February 2022 20:17 CST

cpaschen

This is a request for your opinion/observation related to a custom component that we're creating with the JCB/Joomla Component Builder tool on a site where we have implemented the Admin Password Protect (https://www.akeeba.com/documentation/admin-tools/admin-pw-protection.html).

JCB places rule files (for front-end edit views) on the admin side, so to use the edit form we have to change the password-protect to PHP files only.

The developer of JCB has stated that this type of protection and isolation of functionality between front-end and admin-side is not 'standard' for Joomla components (or Joomla core).

In my own look at the core functionality of Joomla I've not found any areas that store rules or other front-end necessary files on the admin side. And, after using Akeeba Admin Tools for a number of years, and almost always enabling the Password-protect Administrator, I've only experience one other extension (Gantry templates) that have had a similar problem with this (and they fixed that relatively quickly).

So I'm wondering if it is true that isolating front-end functionality from admin-side resources is standard practice for Joomla?

Could you confirm or deny that?

nicholas
Akeeba Staff
Manager

So I'm wondering if it is true that isolating front-end functionality from admin-side resources is standard practice for Joomla?

Correct. It's not just standard practice, it's a basic security precaution.

The administrator application runs privileged operations and must not be publicly accessible. Not even its login page, let alone its files. It is meant to be something insulated from the public eye.

The developer of JCB has stated that this type of protection and isolation of functionality between front-end and admin-side is not 'standard' for Joomla components (or Joomla core).

Bollocks. Sorry for the colourful language, I was trying to find a more eloquent phrase but there's nothing that can convey the utter inaneness, absurdity, ludicrousness and fatuousness of that statement.

Let's take a short history lesson of Joomla and static media file security.

Yes, Joomla 1.0 did not do this separation. Joomla 1.0, released in 2005, was based off Mambo 4 first released in 2003. The security landscape was very different two decades ago. Moreover, Mambo was little more than a side project of an Australian web agency which grew very fast and far beyond its original scope. Joomla 1.0 was merely a fork of that under a new name without any new work done on it. It had inherited 4 ½ years of bad decisions.

Joomla 1.5 was actually the first real Joomla release, meaning that it was code that was specifically written by what was then called the Joomla Core Team as opposed to code inherited from a project with many shortcomings. One of the FIRST things the Core Team did was create the media directory so that all static resources would be placed there, one folder per extension. No more loading static resources from the administrator directory UNLESS it's an administrator page — this allows admin–only templates and admin–only modules and components to operate without placing their static assets to the world–readable media folder. We actually do that in Admin Tools 6, only moving static assets to media/com_admintools in Admin Tools 7 for Joomla 4 for reasons which will become clear further below.

Joomla 3 further entrenched the status of the media folder. Now you didn't just have to place your static assets in one directory per extension, the name of the folder was also prescribed in that it has to use the same naming conventions Joomla uses for extensions e.g. com_something, tpl_whatever, mod_example, plg_folder_something and so on.

Joomla 4 fully made use the media folder mandatory for all static files by having the WebAssetsManager look for the assets manifest (joomla.asset.json) in the prescribed, extension–specific folder in the media directory. You have to go way out of your way to do anything different and it's definitely frowned upon.

These facts are FUNDAMENTAL to developing Joomla extensions. You can't possible write extensions without being aware that the media folder has been around since 2007 (yup, two thousand seven, 15 years ago!) and why it exists. Anyone trying to argue the point is a blathering ignoramus, especially now that Joomla 4 is released and has proven beyond any shred of doubt that using the media folder is a REQUIREMENT for Joomla extensions.

I rest my case.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

cpaschen

Nicholas,

THANK YOU! And esp. thanks for the historical perspective.

I'll share this with the JCB developer group, although when I do I'll probably be asked to help re-work the extension to make it work properly (the fun of community developed extensions :-) ).

Thanks again for the explanation on this.

And thanks for the great tools and advise over the years that have helped to keep all of my many sites secure, without a hack, for many years!

nicholas
Akeeba Staff
Manager

You're welcome!

The funny thing is, reworking the extension is trivial...

Assuming you have a JavaScript file in /media/com_foobar/js/example.min.js the code to include it in Joomla is

Joomla\CMS\HTML\HTMLHelper::_('script', 'com_foobar/example.min.js')

If it's a CSS file the file is /media/com_foobar/css/example.css and the code to include it in Joomla is

Joomla\CMS\HTML\HTMLHelper::_('style', 'com_foobar/example.css')

For images the file is /media/com_foobar/images/example.jpg and the code to include it in Joomla is

echo Joomla\CMS\HTML\HTMLHelper::_('image', 'com_foobar/example.jpg', 'Alt attribute content here')

The js, css and images subfolders are prescribed i.e. they cannot be changed. They are also standard.

Given a template /templates/foobar you can also override these static media files in the folders:

/templates/foobar/media/com_foobar/js/example.min.js

/templates/foobar/media/com_foobar/css/example.css

/templates/foobar/media/com_foobar/images/example.jpg

That's the other two reason why using the Joomla core makes more sense than going full cowboy: i. it's far less and more standardised code; ii. it supports template media overrides. The latter are a massive hidden feature of Joomla. You can ship an extension with CSS (and its SCSS or LESS sources if that's your jam) and your client can completely override it to match their template. Compare that to the Joomla 1.0 way of doing things: load the extension's CSS then load yet another complex file to override the extension's CSS. Lunacy! Joomla 1.5 restored sanity 15 years ago. Why would anyone in their right mind go back to the lunacy of the Joomla 1.0 way once they have found out there's a better way is beyond me. If they have not figured out there's a better way in 15 years... I can understand 1 year, 3 years, maybe 5 years. But 15?!

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!