Developing a component frontend update function/Rethink frontend permissions
From Joomla! Documentation
< J3.x:Developing a component frontend update function
19 Access rights and permissions
The purpose of the back-end pages is typically to perform administrative actions. Permitted users therefore should be administrators of some kind, and the required access rights and permissions are more or less clear.
The purpose of 'cloning' and reusing the 'administration' pages of a component in the front-end can be very different for the various implementations. So presumably each implementation requires rethinking about a suitable strategy for access rights and permissions. This step suggests two particular use cases, and might not be suitable at all in other situations. The implementation part of support for permissions might well be less difficult than developing a proper strategy for it.
The subject of this tutorial is user access to private data items. This implies that the data often is not intended to be publicly visible to the outside world. This is different from for instance data like articles or blogs, where access rights do need to be granted for modification, but there is no permission required to view that data. So the 'standard' Joomla permissions like for edit, delete, create etc are not sufficient, and an additional permission for view is needed.
19.1.1 Use case: prohibit access to the complete component
The most solid restriction is to prohibit any any access to the component at all for users without permissions. As a consequence unpermitted users can not open the private pages in the first place, regardless of whether there was actually data on those pages or not. This is the strategy that for example is also implemented for the back-end admin pages: the outside world can not even see the admin pages without data, let alone with data.
The protection for this is implemented in the base controller for the component. This is the place where all execution of component code start and very easy to implement. The unpermitted user is then stopped right at the beginning.
So if your implementation requires functions comparable to administrative actions by users, while you do not want the concerning users to actually access the administrative back-end, then this implementation might be a good approach for you. It is a kind of admin framework for only this component and running in the front-end, so to speak.
19.1.2 Use case: limit view to none but specifically assigned record item
A more relaxed way of restrictions on visibility of private data is the scenario where existence of data is visible, but its actual content is hidden. So for our case of user greeting data, the outside world might be allowed to see a list of sequence numbers for the existing greetmessages, without being able to actually 'open' the greet item and view its content. For greeting messages this is not really a good example of course, but when the record items contain for instance address info, then the public might be able to view a list of nicknames, but not the actual names, addresses, phone numbers etc.
Another flavor of this scenario is that by default no record items are visible, also not in the overview list, except for the ones that are specifically tagged by the user or admin to be publicly visible. This only concerns the visiblity, not the 'edit' permissions etc. You could think of the case that all greeting messages are invisible, except for the ones from the webmaster and the support desk. (Maybe this is not a very good example ...).
These kind of permission checks are not performed in the base controller, but about at the same place in the code where also the checks for the classic permissions like 'edit', 'delete' etc are implemented.
Both use cases are shown in this step of the tutorial. And that is probably not a real-world scenario because one would presumably make a choice for one of the cases and skip the other.
19.2 The changes
have been updated to reflect new version info.
New messages have been added to the language files.
As already explained in the introduction, the first use case only requires one change in the base controller. The user is checked for permission to access the component at all. Without access the buck stops here.
19.2.3 site/views/helloworld/view.html.php, site/views/helloworld/view.html.php
The second use case is implemented by allowing the public user to view the usual overview list of greeting items, but deny view access to the message content. The 'helloworld' view therefore is extended accordingly while the 'helloworlds' view has not changed.
Note that the admin can still assign public view permission to individual greeting item records as usual.
The existence of new access rights 'helloworld.access' and 'helloworld.view' is defined in this xml file. The corresponding permission can now be set in the component admin pages, either at component level or at record item level.
The most complicated change actually is the install script. Because of the non-standard scenarios the use case may require, or at least prefer, certain permissions already being setup by default at installation time. The postflight function of the installation script script.php is the place to do so.
As an example, the implementation in this tutorial first searches for identification of the unregistered, outside world, 'Public' user. In then searches for the permission setting for the current component, and adds 'helloworld.access' rights to the unregistered user by default, so that the outside world at least can access the component and display the overview list of all greeting messages. Note that the admin can of course revoke this setting again in the global permissions page of the component.
The functionality is implemented by directly accessing the database. This is not very complicated so as such not an issue, but it might be against the (official or intended) Joomla architecture not to use standard Joomla functions for this. As of yet, however, I have not been able to find out what the 'official' approach is supposed to be, and if such functions indeed do exist.
19.3 Source files for this step
19.4 Testing the features of this step
- Prepare users and permissions, and test like previous step. And ...
- This step is primarily about permissions, so test different permission setting both for 'Public', the outside world. And for 'Registered' users with a login account.
- Test the differences between helloworld.access and helloworld.view permissions.