-
Notifications
You must be signed in to change notification settings - Fork 8
The System plugin
SkeletonKey comes with two plugins. One of them is the “System - Skeleton Key” plugin, in Joomla's system group.
This plugin is responsible for three things:
- Displaying the “Login as User” button to backend users
- Creating the necessary tokens and the cookie when you click the “Login as User” button
- Telling Joomla to log you in as another user when the cookie is present (note that this step also requires the “Authentication — Skeleton Key” plugin due to the way Joomla works).
The plugin must be published at all times, with its Access set to Public.
IMPORTANT! You can limit who will see the “Login as User” button rendered by this plugin using the plugin's options. You MUST NOT attempt to do that by changing the plugin's Access setting. Part of what this plugin does happens in the frontend, where you might not already be logged in, therefore the plugin needs to be available even for Guest users to actually do something useful.
Admin Groups tells the plugin which Joomla! user groups will see the “Login as User” button in the backend of the site. By default, this is only the Super Users. Please keep in mind that the user groups you select here must have both backend access, and access to Joomla's Users component i.e. they need the Backend Login privilege in Global Configuration, Permissions and the Access Admin Interface privilege in Users, Options, Permissions.
Allowed Login Groups tells the plugin which users it should allow the “Login as User” to work for. Only user accounts which belong in one or more of the groups listed in this option will have a “Login as User” button. By default, this is set to “Registered”, the default user group Joomla assigns to frontend (but not backend!) users.
Disallowed Login Groups tells the plugin which users it should never allow the “Login as User” to work for. Any user account which belongs in at least one of the groups listed in this option will NOT have a “Login as User” button. By default, this is set to Administrator and Super Users, the two backend user groups with dangerously broad access to Joomla's settings.
Cookie Lifetime (seconds) is a security setting. You should normally not touch it. As already noted, the plugin works by creating a secure cookie. The cookie needs to be allowed to work long enough for the front-end of your site to load, but not too long so as to become a viable target for an attacker to steal and misuse to gain access to your site. The default is 10 seconds which achieves this foal for most sites. If you are on a very slow / high latency Internet connection, slow server, or otherwise your site's frontend usually takes longer than 10 seconds to load you can increase this setting. Please be aware that increasing it beyond 30 seconds is a security risk, as it us the point where a cookie-stealing attack becomes marginally practical.
Key Length is a security setting. You should normally not touch it. It tells the plugin how long (measured in characters) will the randomly generated authorisation code be when you click the “Login as User” button. The default is 32 which makes a brute force (guessing) attack practically infeasible. In the extremely unlikely case you have a database issue you may lower this setting. We do not recommend lowering it below 20.
What happens if a user is both in one of the Allowed Login Groups and one of the Disallowed Login Groups? Disallow wins, and you will NOT see a “Login as User” button for that user.
Likewise, if a user account belongs in neither one of the Allowed Login Groups, nor one of the Disallowed Login Groups then you will NOT see a “Login as User” button for that user.
These two design choices are intentional security features and will not change. In both cases, you will notice that the behaviour matches Joomla's access mantra of “access is denied by default, and explicit disallow always wins over explicit allow”.
The safest way to use SkeletonKey is to have it NOT display a “Login as User” for any user —even though both of its plugins are enabled— unless you explicitly tell it that you want to allow logging in as a specific user.
You can do that by creating a user group, let's call it “Proxy Login for Debugging”. When you create this user group set its parent to “Public”.
Then, edit the “System - Skeleton Key” plugin. Set the “Allowed Login Groups” to “Proxy Login for Debugging” only. Click on Save & Close to apply your settings.
Now, you will see that your user administration looks like it did before you installed SkeletonKey. That's great! That's what we wanted.
Let's say that you want to debug a frontend user's access, therefore you need to log into your site as that user. Go to Users, Manage, edit that user and add them to the “Proxy Login for Debugging” group. You will now see that there is, indeed, a “Login as User” button for that user. Therefore, you can log into your site as that user and perform any troubleshooting necessary. Remember to edit that user again when you're done, and remove them from the “Proxy Login for Debugging” group.
Joomla has an option which unifies the backend and frontend login sessions. You can find it in Global Configuration, System. It's called Shared Sessions.
When Shared Sessions is enabled, both your backend and your frontend login use the same PHP session ID. Therefore, when you use Login as User you are logged out of the backend (administrator) of the site.
Beyond what is explained above regarding Shared Sessions, you may experience being logged out of the backend of your site when you use SkeletonKey even when Shared Sessions is disabled on some browsers, when using a VPN or other proxy to access the Internet, or when you have set up the Cookie Domain and/or Cookie Path in your site's Global Configuration. This is a side-effect of the way Joomla sessions work, namely the way the session cookies work in Joomla.
There is really no workaround to that. You can see it's not a problem with SkeletonKey because logging into the backend of your site also logs you into the frontend of the site, even though Shared Sessions is disabled. It's simply a case of the cookie for both the front- and the backend login having a path of / (root of the site), and the fact that Joomla! always uses the same cookie name for a specific site's login cookie regardless of whether it's the front- or backend (the application identifier, that is to say whether it's frontend or backend, does not participate in the construction of the cookie name).
It is very unlikely you'll bump into that, it's annoying when it happens, and there's nothing that you can actually do about it as far as I can tell.