Español
English
Forum
Table Manager Support
Table Manager SupportForums
Public write access is disabled. Please login
Levels of access (again) 17.08.2014 17:26
I have read the post about adding two forms - one read-only and one editable - and setting different access levels to control who can edit the form.
I've been trying to do that from the start but it doesn't work. Am I missing something.
I create the form - I create a menu item for that form - I set access to "special" (only editors should be able to see it). I log in as a REGISTERED user (not editor or manager etc. - just ordinary REGISTERED user) and when I go to that page / menu item an error appears telling me "your not authorized to view this resource" BUT (and this is a BIG BUT) IT LOADS THE FORM! What is the point of that?
Not happy. Is there an answer to this?
I've been trying to do that from the start but it doesn't work. Am I missing something.
I create the form - I create a menu item for that form - I set access to "special" (only editors should be able to see it). I log in as a REGISTERED user (not editor or manager etc. - just ordinary REGISTERED user) and when I go to that page / menu item an error appears telling me "your not authorized to view this resource" BUT (and this is a BIG BUT) IT LOADS THE FORM! What is the point of that?
Not happy. Is there an answer to this?
Re: Levels of access (again) 18.08.2014 10:00
Hello,
If you create a menu item and set it access to special, if you don't belong to 'special' group (usually Manager, Author, Super User), you shouldn't access to this resource at all, you shouldn't see in menu and, if you try to access directly using url, you should see login form.
If you can see 'special' menu accesing as Registered user, there must be something wrong in acl configuration.
But this is not a Table Manager issue because joomla is in charge of menu acl control.
Regards,
Moonsoft Team
www.moonsoft.es
If you create a menu item and set it access to special, if you don't belong to 'special' group (usually Manager, Author, Super User), you shouldn't access to this resource at all, you shouldn't see in menu and, if you try to access directly using url, you should see login form.
If you can see 'special' menu accesing as Registered user, there must be something wrong in acl configuration.
But this is not a Table Manager issue because joomla is in charge of menu acl control.
Regards,
Moonsoft Team
www.moonsoft.es
Re: Levels of access (again) 18.08.2014 10:34
I understand what you are saying BUT it still happens.
NOT LOGGED IN (PUBLIC):
I don't see the menu option listed - good
AND, if I go to the page via URL directly it shows me a login window - great!
Also, modules and articles set to a higher access are not visible.
LOGGED IN AS REGISTERED:
I don't see the menu option listed - good
BUT, if I go to the page via URL directly it shows me a warning that I am not allowed to access this resource AND then shows me the table (with edit function) - NOT GOOD
YET, modules and articles set to a higher access are not visible - it seems these items work with the ACL because the access for these items is set specifically for each one.
LOGGED IN AS SPECIAL: No problem - I can see the menu item and I get no warnings. All modules and articles set for this access are loaded.
I like your component - please understand that I do (I think there are a few improvements that could make it really shine, but for the most part I like it). Your component has no access settings in the table/component itself, and relies on the ACL of the menu. This is not working. It would be better if you introduced access levels at the individual table level.
I understand ACL well enough and I cannot get around this problem.
I want the public not to see the table even if they get to the page somehow; I want registered users to view it but not edit it; and a special group to be able to edit it if needed. There seems no J! ACL solution for your component at this time.
BTW: Is there something I'm missing about the "autoincrement" setting for the field "edit type"? I set it to autoinc and it does not autoincrement - the user has to add it manually (if they don't then the record is not added to the table). I though the point of autoinc was that the field was populated automatically by SQL on insert. ???
And, clearer documentation (and more of it) would be nice too.
NOT LOGGED IN (PUBLIC):
I don't see the menu option listed - good
AND, if I go to the page via URL directly it shows me a login window - great!
Also, modules and articles set to a higher access are not visible.
LOGGED IN AS REGISTERED:
I don't see the menu option listed - good
BUT, if I go to the page via URL directly it shows me a warning that I am not allowed to access this resource AND then shows me the table (with edit function) - NOT GOOD
YET, modules and articles set to a higher access are not visible - it seems these items work with the ACL because the access for these items is set specifically for each one.
LOGGED IN AS SPECIAL: No problem - I can see the menu item and I get no warnings. All modules and articles set for this access are loaded.
I like your component - please understand that I do (I think there are a few improvements that could make it really shine, but for the most part I like it). Your component has no access settings in the table/component itself, and relies on the ACL of the menu. This is not working. It would be better if you introduced access levels at the individual table level.
I understand ACL well enough and I cannot get around this problem.
I want the public not to see the table even if they get to the page somehow; I want registered users to view it but not edit it; and a special group to be able to edit it if needed. There seems no J! ACL solution for your component at this time.
BTW: Is there something I'm missing about the "autoincrement" setting for the field "edit type"? I set it to autoinc and it does not autoincrement - the user has to add it manually (if they don't then the record is not added to the table). I though the point of autoinc was that the field was populated automatically by SQL on insert. ???
And, clearer documentation (and more of it) would be nice too.
Re: Levels of access (again) 18.08.2014 10:52
To add (to be clear):
If I create a module or article and set it to "public" access it will show anywhere it is assigned - even in pages where the menu-item is set to a higher access level. This only happens for LOGGED-IN users - this doesn't happen to "PUBLIC" access. If you are not logged in you cannot see the pages or any content set to a higher ACL.
If you are logged in at ANY level you will see any content at your ACL level or below regardless of the menu ACL setting. This is a flaw in the J! ACL as far as I am concerned.
This is a J! ACL issue - sure - but it is one to which your component is vulnerable because you rely on the menu ACL.
If I create a module or article and set it to "public" access it will show anywhere it is assigned - even in pages where the menu-item is set to a higher access level. This only happens for LOGGED-IN users - this doesn't happen to "PUBLIC" access. If you are not logged in you cannot see the pages or any content set to a higher ACL.
If you are logged in at ANY level you will see any content at your ACL level or below regardless of the menu ACL setting. This is a flaw in the J! ACL as far as I am concerned.
This is a J! ACL issue - sure - but it is one to which your component is vulnerable because you rely on the menu ACL.
Re: Levels of access (again) 18.08.2014 11:46
Hello,
We don't see it as a J! ACL issue, it's working as expected, according to official joomla docs. In some websites is needed to add a new group attached to root (not to Registered) and create other access level assigned to this new group. This prevent registered users show menu items assigned to this access level.
If you place a ticket sharing your site access we can take a look.
About autoincrement field, please double check that, if your table already has records, all values in autoincrement column only contain numbers.
Regards,
Moonsoft Team
www.moonsoft.es
We don't see it as a J! ACL issue, it's working as expected, according to official joomla docs. In some websites is needed to add a new group attached to root (not to Registered) and create other access level assigned to this new group. This prevent registered users show menu items assigned to this access level.
If you place a ticket sharing your site access we can take a look.
About autoincrement field, please double check that, if your table already has records, all values in autoincrement column only contain numbers.
Regards,
Moonsoft Team
www.moonsoft.es
Re: Levels of access (again) 18.08.2014 13:03
I tried that - it doesn't fix it.
[ADDED] I changed the menu ACL viewing setting to SUPER USER, and still anyone logged in can see it. [END EDIT]
Joomla's approach to this problem is like this:
ACTION: If a public user tries, via URL, to access a page with an associated menu ACL requiring log-in (anything above PUBLIC).
RESPONSE: J! prompts for a LOG-IN.
Once you're logged in however, this response is no longer available to J! - You're already logged in so it can't get you to log-in again.
1. You try to access a "registered" ACL page via URL from public access - J! asks for login.
2. Once logged in, J! can't ask you to log in again, so...
3. At this point J! relies on the individual ACL settings for the elements assigned to that page in order to control viewing rights.
So, if an assigned module has a "public" ACL then anyone logged in can see it, even if the menu ACL has a restriction.
I've tried it in all combinations. While your component relies on the menu to control access this will happen. What you would need to do is tell your component to inherit its viewing access rights from the menu ACL setting.
I'm going to use your component to show the table to any logged in user, and find a form module, where I can set the ACL in the module, to insert data. Seems like the only solution.
Edited by moon_1771 - 18.08.2014 13:11
[ADDED] I changed the menu ACL viewing setting to SUPER USER, and still anyone logged in can see it. [END EDIT]
Joomla's approach to this problem is like this:
ACTION: If a public user tries, via URL, to access a page with an associated menu ACL requiring log-in (anything above PUBLIC).
RESPONSE: J! prompts for a LOG-IN.
Once you're logged in however, this response is no longer available to J! - You're already logged in so it can't get you to log-in again.
1. You try to access a "registered" ACL page via URL from public access - J! asks for login.
2. Once logged in, J! can't ask you to log in again, so...
3. At this point J! relies on the individual ACL settings for the elements assigned to that page in order to control viewing rights.
So, if an assigned module has a "public" ACL then anyone logged in can see it, even if the menu ACL has a restriction.
I've tried it in all combinations. While your component relies on the menu to control access this will happen. What you would need to do is tell your component to inherit its viewing access rights from the menu ACL setting.
I'm going to use your component to show the table to any logged in user, and find a form module, where I can set the ACL in the module, to insert data. Seems like the only solution.
Edited by moon_1771 - 18.08.2014 13:11
Re: Levels of access (again) 18.08.2014 13:29
Hello,
We're assuming that your were using Table Manager as menu item, not as module. In fact, Table Manager has no module view. So, you're using any module wrapper or any other component to publish? This way you will be inhereting all joomla acl behaviour.
Regards,
Moonsoft Team
www.moonsoft.es
We're assuming that your were using Table Manager as menu item, not as module. In fact, Table Manager has no module view. So, you're using any module wrapper or any other component to publish? This way you will be inhereting all joomla acl behaviour.
Regards,
Moonsoft Team
www.moonsoft.es
Re: Levels of access (again) 18.08.2014 13:40
On auto-increment:
Maybe its a lack of documentation, I don't know but I can't work it out.
When I created my dummy table it had a "member_number" field - integers in acceding order by 1.
That loaded into the table on the DB.
When I came to configure the fields for MStable associated with this DB table, it asked for "edit type" and gives a drop down of choices "no-edit, number, text, text box, calculate..." - the one I selected is "auto-increment".
BUT, by choosing this option it makes the field editable on the form - the whole point of autinc is that it is fixed permanently (no editing). I don't want a user to change this value under any circumstance.
To fix that I have to set the field to "no edit". But then I can't get the filed to autoinc on insert - it just NULLs (if it inserts at all).
And, if I allow it to be included in the ADD FORM than the user has to add the value - again, the point of autoinc is that it is unchangeable, fixed, and inevitable. The user should have no control over this value.
Again, perhaps I am missing something due to the dearth of documentation. I do understand what a autoinc field is for but can't see how it worls in MStables.
Maybe its a lack of documentation, I don't know but I can't work it out.
When I created my dummy table it had a "member_number" field - integers in acceding order by 1.
That loaded into the table on the DB.
When I came to configure the fields for MStable associated with this DB table, it asked for "edit type" and gives a drop down of choices "no-edit, number, text, text box, calculate..." - the one I selected is "auto-increment".
BUT, by choosing this option it makes the field editable on the form - the whole point of autinc is that it is fixed permanently (no editing). I don't want a user to change this value under any circumstance.
To fix that I have to set the field to "no edit". But then I can't get the filed to autoinc on insert - it just NULLs (if it inserts at all).
And, if I allow it to be included in the ADD FORM than the user has to add the value - again, the point of autoinc is that it is unchangeable, fixed, and inevitable. The user should have no control over this value.
Again, perhaps I am missing something due to the dearth of documentation. I do understand what a autoinc field is for but can't see how it worls in MStables.
Re: Levels of access (again) 18.08.2014 13:42
Of course I'm using it as a menu item - the component does not come as a module.
I used the description above with "modules" as an example. The same goes for articles or any other element assigned to that menu item. Your component is not assigned to the menu item - its embedded. I can only assign it to one menu item at the time of creating that menu item.
Edited by moon_1771 - 18.08.2014 13:46
Edited by moon_1771 - 18.08.2014 13:47
So, if an assigned module has a "public" ACL then anyone logged in can see it, even if the menu ACL has a restriction.
I used the description above with "modules" as an example. The same goes for articles or any other element assigned to that menu item. Your component is not assigned to the menu item - its embedded. I can only assign it to one menu item at the time of creating that menu item.
Edited by moon_1771 - 18.08.2014 13:46
Edited by moon_1771 - 18.08.2014 13:47
Re: Levels of access (again) 18.08.2014 14:37
I've tried this out on 2 separate installs of J!3.3.3
I've tried 2 different default themes - protstar and beez3
Same result.
Joomla is running a logic like this:
USR (acl=public) >>> request via URL >>>> PAGE/MENU (acl=special) >>> Check rights = USR (acl=public) too low >>> request login >>>
--LOGIN--
USR (acl=public) >>> login >>> success >>> change USR (acl=registered) >>>
USR (acl=registered) >>> continue request via URL >>> PAGE/MENU (acl=special) >>> Check rights = USR (acl=registered) too low >>> request login >>> USR = logged in already >>> Warning msg = "can't view content" >>>
At this point it should DIE, but it doesn't...
LOAD MSTables (acl=public/not-set???) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned COMPONENT1 (acl=special) >>> check rights = USR (acl=registered) too low >>> DIE;
LOAD assigned MODULE1 (acl=public) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned COMPONENT2 (acl=registered) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned ARTICLE (acl=special) >>> check rights = USR (acl=registered) too low >>> DIE;
...
The menu ACL setting does not over-ride the assigned components. I think categories will over-ride articles, but it looks like menu ACL does not.
Edited by moon_1771 - 18.08.2014 14:38
Edited by moon_1771 - 18.08.2014 14:39
Edited by moon_1771 - 18.08.2014 15:15
Edited by moon_1771 - 18.08.2014 15:21
I've tried 2 different default themes - protstar and beez3
Same result.
Joomla is running a logic like this:
USR (acl=public) >>> request via URL >>>> PAGE/MENU (acl=special) >>> Check rights = USR (acl=public) too low >>> request login >>>
--LOGIN--
USR (acl=public) >>> login >>> success >>> change USR (acl=registered) >>>
USR (acl=registered) >>> continue request via URL >>> PAGE/MENU (acl=special) >>> Check rights = USR (acl=registered) too low >>> request login >>> USR = logged in already >>> Warning msg = "can't view content" >>>
At this point it should DIE, but it doesn't...
LOAD MSTables (acl=public/not-set???) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned COMPONENT1 (acl=special) >>> check rights = USR (acl=registered) too low >>> DIE;
LOAD assigned MODULE1 (acl=public) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned COMPONENT2 (acl=registered) >>> check rights = USR (acl=registered) OK >>> EXEC;
LOAD assigned ARTICLE (acl=special) >>> check rights = USR (acl=registered) too low >>> DIE;
...
The menu ACL setting does not over-ride the assigned components. I think categories will over-ride articles, but it looks like menu ACL does not.
Edited by moon_1771 - 18.08.2014 14:38
Edited by moon_1771 - 18.08.2014 14:39
Edited by moon_1771 - 18.08.2014 15:15
Edited by moon_1771 - 18.08.2014 15:21
Re: Levels of access (again) 18.08.2014 16:30
Hello,
When we use Table Manager as menu item it works ok with different access levels an users. If you want us to take a look, please place a helpdesk with credentials, users and an specific secuence to reproduce it.
Regards,
Moonsoft Team
www.moonsoft.es
When we use Table Manager as menu item it works ok with different access levels an users. If you want us to take a look, please place a helpdesk with credentials, users and an specific secuence to reproduce it.
Regards,
Moonsoft Team
www.moonsoft.es
Re: Levels of access (again) 18.08.2014 20:22
Its not just your component that does this. It happens with all components (articles, modules, etc.) if they are assigned to a menu item/page.
When a menu view access is restricted to "super user" only and still the components load on a page when logged in as "Registered User", there is a problem with J!. These are fresh unaltered J!3.3.3 installs.
I'll just put up with it, or switch to WordPress - which I swore I'd never do, but as the years roll on their approach to design and their CMS has improved.
When a menu view access is restricted to "super user" only and still the components load on a page when logged in as "Registered User", there is a problem with J!. These are fresh unaltered J!3.3.3 installs.
I'll just put up with it, or switch to WordPress - which I swore I'd never do, but as the years roll on their approach to design and their CMS has improved.
Re: Levels of access (again) 19.08.2014 10:42
Hello,
We tries to reproduce here some kind of error with ACL with some users, groups and level access. We still think Joomla ACL works as expected.
If you want to restrics a page only for 'Super user', you should add a new access level with only 'super users' group because none of default access levels include only 'super users'. If you don't add a new access level, we don't know how to restrict only for 'super user',please note that 'special' access level include also Author (Registered) and Manager groups.
Regards,
Moonsoft Team
www.moonsoft.es
We tries to reproduce here some kind of error with ACL with some users, groups and level access. We still think Joomla ACL works as expected.
If you want to restrics a page only for 'Super user', you should add a new access level with only 'super users' group because none of default access levels include only 'super users'. If you don't add a new access level, we don't know how to restrict only for 'super user',please note that 'special' access level include also Author (Registered) and Manager groups.
Regards,
Moonsoft Team
www.moonsoft.es