FREELessons: 35Length: 7.7 hours

Next lesson playing in 5 seconds

  • Overview
  • Transcript

2.3 Introducing Permissions and Security

We’ll now look extensively at the permission system within Joomla, which is vital to the security of your CMS. Also with security in mind we’ll look at the text filtering to prevent malicious code being injected or prevent inappropriate commenting.

2.3 Introducing Permissions and Security

Hi guys, welcome back to A Beginner's Guide to Using Joomla! And in this lesson, we're going to carry on looking at those global configurations, so continuing on from where we last left off, we have the global configuration, and now we're on the server tab. So the first option we have on the server settings is the path to the temp folder. Now again whenever transferring your Joomla installation to the cloud. Always check this directory. And this is where all the temp files will be stored. We have the G-Zip page compression. So this compresses those files so they're smaller. And that means that it can be transferred over a network a lot quicker. Now it's a bit more taxing on the server but it's recommended that you actually have G-Zip compression set to on or yes. Now we also have error reporting for system administrators. So we can have the system default. We can have none, which means no error reporting. Simple error reporting is only going to report fatal errors, you know the serious stuff. Maximum will give us everything. It'll give us notices, warnings, deprecated functions, and also the fatal errors as well. So it's recommended that you set it to maximum so that you can get as much information as possible. And finally you have development. Now on top of that we have force SSL which is secure socket layer. Which means that the data between the user's browser and the cloud is encrypted so you can't get eavesdroppers looking at that information. Now it's not a good idea to set your entire site to https. So if I say entire site and save it, it will have the back-end now on https, so all of that is encrypted, which is good. But, however, the front-end will also be https as well. Now also, if you are going to have an SSL connections, it's recommended that you have a certificate, which does cost money, but it ensures that it verifies your identity and your users may feel a lot more secure on your server. But SSL in general is a bit overboard if all I'm going to do is read a few blog articles. SSL is really there for, let's say, user logins and administrator logins, which you can set right here. So we say, Force SSL Administrator Only. So the administrator's information and data is encrypted between their browser and the server. But the average Joe Public doesn't need that https encryption. That's up to you I'm going to bring that back down to none, so now we don't have https encryption. Now on top of that, we have the location settings, so the server time zones, again I can search for a particular time zone if I want to. The FTP settings. So, let's say that I'm struggling to upload content such as images and so forth in Joomla, and it's always failing I cannot get anything to upload. It generally means your server configuration is a little bit different, and so, you're going to need to enable ftp. Hit yes, and then you need to provide your ftp details. You also need to speak to your host so that you can resolve the problem. And they should be able to provide you with this information. But because of the way the server is setup, it may stop Joomla with a default functionality of uploading so you also need to enable ftp. Now also you have Proxy as well which you can enable. Again you need to contact your host to get the relevant information. Then also we have the Database Settings. So we have the Database Type, which we're currently using MySQLi. The host which is localhost. The Database Username, which is root. The Database Name, and also the Database Tables Prefix. Now this is modifying the configuration.php file. You need to be very careful because if you change these settings and save them, it's going to change that configuration.php file. And it could end up screwing up the connection to the data base and therefore your Joomla installation won't work. So be very careful with editing those settings. We also have the mail settings, so do you want to enable the ability to send mail, yes or no? Typically you would. Then we have the mailer. So normally you would leave it as php mail. But you can use send mail and SMTP. It's recommended that if your service supports php mailer you use php mail. It's the easiest way. Then we have from email. So this is the site email. So make sure you don't actually put your own personal email address in here. Also, you have the from name. So the name associated with that email address. Typically that will be your company name rather than a personal name. Next up we have the permissions. So with Joomla we have the ability to set permissions for a whole range of things including any extension, including any plugin or even any component. So I can say, right, only certain user groups can access articles and create articles. I can also say only certain user groups can access the Joomla Update, and so on, and so forth. So, Joomla gives you really great control over the permissions, but it can be a little bit tricky to get started with. So, if we take a look at the permissions, on the left hand side, we have the different user groups. And these dashes indicate which group is nested inside of which group. On the left hand side we have the action, so what is that user group allowed to do. And we get a general overview of each action if we hover over it. And then we can either say Not Set, Allowed, Denied or there's another one called inherited but we'll talk about that in just a second. But right now we have first of all the public, which doesn't have a little dash next to it. Now, every single user groups from guest all the way to super users, is a child of the public. Because don't forget, we're all classes to Public, until we log in and then we can go to the Administrator, or the Super Users permission set. So we're all classed as the Public until we log in. So in the moment you can see the Public right now. But then we also have Guest with a dash next to it. That tells me this a direct child of the Public. The manager user group is a direct child of the public. Now the administrator has two dashes. So this means this is a direct child of the manager user group and that's a direct child of the public. Now on top of that we have registered again a direct child to the public. Then we have an Author, with two dashes, which is a direct child to the Registered. See one, and then two. And then we have three dashes for the editor. So three dashes tells me that the editor is a group, within the Author group, within the Registered group which is in the Public. And then finally you have Publisher, which you see one, two, three, four. So it's in that group, and that group, and then that group, and then that's to the Public. So you can see by those little dashes we can easily tell. And then finally, you have the Super Users with Ultimate permissions over the content management system and it's definitely recommended that with super users, they have access to everything. Now most people get confused with the Joomla permissions system but it's not, it's very simple. Most people will be looking at this and seeing okay well we're on the public. And right now even access to the administrator interface is not set. Now you would've thought that would've been on Denied. You really wouldn't want the public to gain access to the administrator interface. But the answer is no. The reason being is because the public does not pose a threat to the Joomla installation. So what do I mean by this? Well even if they wanted to create an article, or access the administrator interface. And I set all of this to allowed, which is not recommended. They still wouldn't be able to bypass the login, so for example, if they wanted to gain access to the administrator interface, even though I put it as allowed here, they still can't gain access until they provide a user name and a password. In fact if I set them all to allowed it doesn't matter, they will not be able to get access to the administrator interface until they provide a user name and password. So with the public it doesn't actually pose a threat. But when they log in that's when they pose a threat. Only when a user logs in can they start to affect the way the content management system looks and works. So this is where your Missions need to kick in and say you are allowed to do this, or you are not allowed to do this. So this is why always on Not Set. It doesn't really need to be set because the public doesn't post a threat. It's only when they start to login do they then pose a threat. Now it would be a very big mistake to say write access to the administrator interface is allowed. So let's go ahead and save that and see what happens. Well, by default with all of these sub user groups of the public, they by default or normally, they are on inherited. So, you can see that these are all inherited. Now, the problem is with inherited, it inherits from the direct parents. So, in the case of the guest, there's only one dash here which means that it's a direct child of the Public. And so it inherit from that. So now guests have access to the administrator interface, because it's inheriting that from the public. That's why you ought to leave it as not set. So I can just say not set right there, and then leave it up to the user group. So now if I go ahead and save this and then we go back. Now the guest, you can see here, it is not allowed access to the administrator interface. Now that doesn't mean you can't override it. You don't have to stick with Inherited, which means it's going to inherit from the parent. You can actually set this to allowed or set it to denied. So for example let's override this permission right here for site login. I'm going to say allowed. So now users have the ability to access the site login. Go ahead and save it. And then when we go over to the permissions, you can see that it's saying allowed right here, because I've overridden it. So I'm going to change that back to Inherited. And that way, by default, when you have the Public permission as not set, it will by default say not allowed. Not let's have a look at those nested user groups. So, first of all we have the manager, which again, only has one dash which means it's a direct child of the public. Now, you'll see here site login, admin login, offline access, they're all set to allowed. So, let's just take these three as an example. So these have now been overridden and Allowed for the Managers. Now let's take a look at the Administrator. So the Administrator is nestled inside of the Managers user group. So I'm going to click on that. Now you can see this is inherited, inherited, and inherited for those three missions. And that's because it's inheriting from the parent. So the parent in the case of the administrator because it has two dashes there. Is the manager. And so it's inheriting those permissions from the direct parent. It's no longer inheriting it from the public. And again you can override that by saying well I want that denied. So I can save that then we can go to permissions, administrator and now we've overridden it and said it's not allowed. So, that, hopefully, will give you an insight in to permissions and you can play around with the permissions right here and just have a look at what you're going to be giving access to and what you're going to allow them to do. And all you need to do is just hover over there. Have a quick read, and then you can determine whether that specific user group has the ability to do that specific action. Now we want to move on to text filters. Text filtering is very important to the security of your content management system. And depending upon which user that group is in, you can have more restrictive filtering, or less restrictive. So for example with the public we put in the filtering of no html. So let's say I have a comment form on my article and the public can comment and I say no HTML, they can not submit any HTML into the comment section. This is good because it's going to stop them from posting YouTube videos, it could be offensive or an advertisement. Now on top of that we can have more trusted users, such as guests, which have the default blacklist. Now, if you scroll down you get a nice yellow box with information about the filters. If you have the default blacklist it will blacklist all of these tags and all of these attributes. Now you can be more restrictive by saying custom black list. What this will allow you to do is blacklist all of these tags and all of these attributes by default but you can also blacklist more. So, for example, with Custom Blacklist I could say I want to blacklist the p tag and also I want to blacklist the b tag as well. And with the attributes I also want to disable the ID attribute and the class attribute as well. Now to be more restrictive or less restrictive. We can say white list. This means that currently all the tags and attributes are banned until we allow it. So I'm going to allow the paragraph, and the b tag, and the i tag. And I'm also going to allow the ID and the class attributes as well. And all you need to do is separate them out with commas, as you can see. And these are now allowed. Now if the most trusted groups you can say no filtering so they can put whatever html they like into the content. So thank you for watching me in this lesson. And please join me in the next one where we'll take a look at the check in, cache and system info.

Back to the top