front-end admin view (edit/form) trying to access admin area of site - being blocked by admin security #846

Closed
opened 2021-12-30 00:16:07 +00:00 by cpaschen · 9 comments
cpaschen commented 2021-12-30 00:16:07 +00:00 (Migrated from github.com)

Steps to reproduce the issue

  • Create component with an admin view
  • Make that admin view accessible from front end with a menu
  • restrict access to admin area of Joomla site (htaccess/htpassword)
  • Open the view on the front-end

Expected result

Able to access the admin view

Actual result

Get blocked asking for log-in to admin site.
This prevents component to work properly on front-end of site with admin restricted.

System information (as much as possible)

  • OS Name & Version: Linux Ubuntu
  • MySql Version: 5.5.5
  • Apache Version:
  • PHP Version: 7.4.27
  • Joomla Version: 3.10.3
  • JCB Version: 2.12.14
  • Browser: Firefox / Brave

Additional comments

I think this might be caused by the fact that the xml file
/components/COMPONENT/models/forms/VIEW.sml

is adding the following lines at the top of the form:

addrulepath="/administrator/components/COMPONENT/models/rules" 
addfieldpath="/administrator/components/COMPONENT/models/fields" 

which obviously are located in the admin area.

I guess I could somehow manually allow access to those areas from the front-end; however, I'm wondering if this should be using a relative path (like com_config, com_users, and several other extensions that I checked use). And they all appear to have the necessarily rules added to the front-end (/component) area, rather than needing to access the admin area.

It appears that only JCB-generated components are forcing the component to access the admin for these rules and fields areas.

### Steps to reproduce the issue * Create component with an admin view * Make that admin view accessible from front end with a menu * restrict access to admin area of Joomla site (htaccess/htpassword) * Open the view on the front-end ### Expected result Able to access the admin view ### Actual result Get blocked asking for log-in to admin site. This prevents component to work properly on front-end of site with admin restricted. ### System information (as much as possible) - OS Name & Version: Linux Ubuntu - MySql Version: 5.5.5 - Apache Version: - PHP Version: 7.4.27 - Joomla Version: 3.10.3 - JCB Version: 2.12.14 - Browser: Firefox / Brave ### Additional comments I think this might be caused by the fact that the xml file /components/COMPONENT/models/forms/VIEW.sml is adding the following lines at the top of the form: ``` addrulepath="/administrator/components/COMPONENT/models/rules" addfieldpath="/administrator/components/COMPONENT/models/fields" ``` which obviously are located in the admin area. I guess I could somehow manually allow access to those areas from the front-end; however, I'm wondering if this should be using a relative path (like com_config, com_users, and several other extensions that I checked use). And they all appear to have the necessarily rules added to the front-end (/component) area, rather than needing to access the admin area. It appears that only JCB-generated components are forcing the component to access the admin for these rules and fields areas.

This behavior of .htaccess blocking to the admin area of the site is not in the scope of JCB. This practice in not used in any of Joomla official websites that all run on Joomla. So I don't think I will be able to resolve this issue anytime soon, as it is not best practice. Not saying its not a smart idea, and useful... just that I have not fully implemented total front-end independence in JCB and will probably never do that, unless it becomes an Joomla official practice.

This behavior of .htaccess blocking to the admin area of the site is not in the scope of JCB. This practice in not used in any of Joomla official websites that all run on Joomla. So I don't think I will be able to resolve this issue anytime soon, as it is not best practice. Not saying its not a smart idea, and useful... just that I have not fully implemented total front-end independence in JCB and will probably never do that, unless it becomes an Joomla official practice.
cpaschen commented 2021-12-30 19:09:25 +00:00 (Migrated from github.com)

Sorry, just to share my experience ... I've been using Joomla in this way (using .htaccess blocking the admin area) for probably 5+ years. It is a basic feature of Akeeba Admin Tools and recommended by a number of Joomla security 'gurus'.
And I have NEVER had a problem with this with any of my other extensions than ones created with JCB.
Additionally, as noted above, both com_config and com_users put their rules in the front-end area. So I think that shows that core Joomla extensions ARE separating the front-end from the admin, at least for this sort of basic functionality from the front-end.

I'm going to check with Nicholas at Akeeba to see if he has any recommendations on this specifically and I'll share here once I hear back from him (i.e. specific work-arounds or best practices).

Sorry, just to share my experience ... I've been using Joomla in this way (using .htaccess blocking the admin area) for probably 5+ years. It is a basic feature of Akeeba Admin Tools and recommended by a number of Joomla security 'gurus'. And I have NEVER had a problem with this with any of my other extensions than ones created with JCB. Additionally, as noted above, both com_config and com_users put their rules in the front-end area. So I think that shows that core Joomla extensions ARE separating the front-end from the admin, at least for this sort of basic functionality from the front-end. I'm going to check with Nicholas at Akeeba to see if he has any recommendations on this specifically and I'll share here once I hear back from him (i.e. specific work-arounds or best practices).

No need for any apologizes, I am just not planning to change this issue any time soon. The rules and forms are pulled from the admin area at this time in Joomla 3.

I may change this going to Joomla 4... so as I said I am not planning resolve this issue anytime soon for J3 components build with JCB.

Honestly locking the back-end with .htaccess when you have multiple back-end users is just not practical. as it means less security as they all need folder access to turn of the restriction if they need access. I see this approach more like a quick fix, instead of better server security.

I have many, many websites, some for governments some for large corporations, and I have never needed this kind of solution.

Side note: You can write your own plugin to move these files and to update those xml values... the compiler has enough events to manage that, I think...

No need for any apologizes, I am just not planning to change this issue any time soon. The rules and forms are pulled from the admin area at this time in Joomla 3. I may change this going to Joomla 4... so as I said I am not planning resolve this issue anytime soon for J3 components build with JCB. Honestly locking the back-end with .htaccess when you have multiple back-end users is just not practical. as it means less _security_ as they all need folder access to turn of the restriction if they need access. I see this approach more like a quick fix, instead of better server security. I have many, many websites, some for governments some for large corporations, and I have never needed this kind of solution. Side note: You can write your own plugin to move these files and to update those xml values... the compiler has enough events to manage that, I think...
cpaschen commented 2021-12-30 20:12:16 +00:00 (Migrated from github.com)

OK ... I think we have a topic for our next JUG ... you sharing some of those 'better server security' measures.
I'm definitely looking for other options that are better.

And I might try creating a plugin to move those files and XML changes - if only to improve my plugin-writing skills.

BTW ... thanks for the WASABI mention in the previous meeting. That has saved me over AmazonS3.

Although not a JCB topic, if you or anyone else has specific ways to secure the admin area, without locking it down with .htaccess I'd love to know them.

OK ... I think we have a topic for our next JUG ... you sharing some of those 'better server security' measures. I'm definitely looking for other options that are better. And I might try creating a plugin to move those files and XML changes - if only to improve my plugin-writing skills. BTW ... thanks for the WASABI mention in the previous meeting. That has saved me $$ over AmazonS3. Although not a JCB topic, if you or anyone else has specific ways to secure the admin area, without locking it down with .htaccess I'd love to know them.

If your using WASABI you should use https://restic.readthedocs.io/en/stable/ as your backup solution.

If your using WASABI you should use https://restic.readthedocs.io/en/stable/ as your backup solution.
cpaschen commented 2021-12-31 18:28:03 +00:00 (Migrated from github.com)

Yup. I've got Restic on my 2022 to-do list.
It's hard keeping up with all these great solutions you keep finding! :-)

Yup. I've got Restic on my 2022 to-do list. It's hard keeping up with all these great solutions you keep finding! :-)
cpaschen commented 2022-01-08 17:55:00 +00:00 (Migrated from github.com)

I finally got a response from Nicholas related to this issue (isolating the admin access).
It confirms my original premise that the front-end should not be accessing the front-end.

It's a bit 'raw' (as Nicholas can get), but I think it makes clear that we really shouldn't be using cross/area calls (from front-end to admin) for any reason.

https://www.akeeba.com/support/admin-tools/Ticket/36362:password-protect-administrator-blocks-component-on-front-end.html

Is there a possibility that this could be re-assessed and added to the roadmap (at least for J4 release)?

IF I find time, I might try to look at the code myself, but I have not ventured into the JCB code itself yet and don't have any sort of functional understanding of it, so I'm a bit concerned about breaking it more than I fix it.

I finally got a response from Nicholas related to this issue (isolating the admin access). It confirms my original premise that the front-end should not be accessing the front-end. It's a bit 'raw' (as Nicholas can get), but I think it makes clear that we really shouldn't be using cross/area calls (from front-end to admin) for any reason. https://www.akeeba.com/support/admin-tools/Ticket/36362:password-protect-administrator-blocks-component-on-front-end.html Is there a possibility that this could be re-assessed and added to the roadmap (at least for J4 release)? IF I find time, I might try to look at the code myself, but I have not ventured into the JCB code itself yet and don't have any sort of functional understanding of it, so I'm a bit concerned about breaking it more than I fix it.
cpaschen commented 2022-04-16 00:14:15 +00:00 (Migrated from github.com)

Side note: You can write your own plugin to move these files and to update those xml values... the compiler has enough events to manage that, I think...

Just curious if this sort of thing is in any way going to be 'easier' to implement once we get into J4 and all the powers functionality is going?
OR will it still require a plugin?

I just don't want to take the time to create a plugin if I'll just have to re-do the work (or the powers workflow might be significantly different).

BTW ... most sites I'm using this on only have one admin (plus me as dev) accessing admin.

ALSO ... this might be a topic for a future JUG - you could share what other security measures you (or others) are using to protect the admin. on security-critical sites.

Side note: You can write your own plugin to move these files and to update those xml values... the compiler has enough events to manage that, I think... Just curious if this sort of thing is in any way going to be 'easier' to implement once we get into J4 and all the powers functionality is going? OR will it still require a plugin? I just don't want to take the time to create a plugin if I'll just have to re-do the work (or the powers workflow might be significantly different). BTW ... most sites I'm using this on only have one admin (plus me as dev) accessing admin. ALSO ... this might be a topic for a future JUG - you could share what other security measures you (or others) are using to protect the admin. on security-critical sites.
cpaschen commented 2022-06-27 21:55:29 +00:00 (Migrated from github.com)

Any chance we could add this to some future discussion time?
Either including it as an option in J4 or how to create a plugin to do it (or possibly with powers?)

This is a pretty common practice for securing admin files (see Nicholas' from Akeeba's responses linked above).
Also, you can have multiple log-ins (one for each person) with a htpassword file, so you don't need to share a password. They can each have their own. And that is only needed for those that need access to the admin - which is rather small number of people for most small business clients. We've been doing it for years without a problem (security issues or functionality problems).

Additionally, I have at least one client project where we must have this in place or I need to know some other means that provides server-level security on admin assets across the entire Joomla file structure that will work.

BTW ... the decision/functionality of JCB here is effecting ALL other aspects of Joomla site. Because right now we can't enable this on the Joomla site at all because JCB breaks, but doing so leaves other files/assets potentially un-protected.

If there are any docs or videos where this has done (to write a plug-in for the compiler for similar function) please let me know and I'll go learn how to do it.

Any chance we could add this to some future discussion time? Either including it as an option in J4 or how to create a plugin to do it (or possibly with powers?) This is a pretty common practice for securing admin files (see Nicholas' from Akeeba's responses linked above). Also, you can have multiple log-ins (one for each person) with a htpassword file, so you don't need to share a password. They can each have their own. And that is only needed for those that need access to the admin - which is rather small number of people for most small business clients. We've been doing it for years without a problem (security issues or functionality problems). Additionally, I have at least one client project where we must have this in place or I need to know some other means that provides server-level security on admin assets across the entire Joomla file structure that will work. BTW ... the decision/functionality of JCB here is effecting ALL other aspects of Joomla site. Because right now we can't enable this on the Joomla site at all because JCB breaks, but doing so leaves other files/assets potentially un-protected. If there are any docs or videos where this has done (to write a plug-in for the compiler for similar function) please let me know and I'll go learn how to do it.
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: joomla/Component-Builder#846
No description provided.