Skip to content

Hiding in the frontend or backend

Nicholas K. Dionysopoulos edited this page Jun 25, 2024 · 4 revisions

Ever since version 4.8.2 released in late June 2024, all SocialLogin plugins allow you to choose whether to show them only in the frontend of your site, only in the backend of your site, or in both frontend and backend (default). You can change that by editing the corresponding plugin in the sociallogin group and changing its “Login buttons can be shown in” option.

Use cases

This feature is was introduced with the intent of supporting special uses cases where social login is only desirable on only one side of the site. It is NOT a security feature, as you can read further down below. We'll explain some use cases to help you understand why this feature exists.

Sites without a frontend login. Many company presentation, news, portal etc sites do not have or need a frontend login. No users should be created, nor do any users need to log into the frontend of the site. The site is fully managed through the backend. If your organisation has a Microsoft 365 Business or G Suite subscription it makes sense that you'd want to use SocialLogin to allow your backend users to log in using their existing Microsoft or Google accounts respectively. At the same time, you know that you cannot completely hide Joomla's login page; e.g. accessing the index.php?option=com_users URL on most sites will show the Users component's login page. You don't want the SocialLogin buttons to appear there, confusing anyone who landed there for whatever odd reason. Hence the need to only show the SocialLogin buttons in the backend of the site.

Personalised sites such as forums, community hubs, e-commerce sites, etc. The goal of using SocialLogin with these sites is to reduce the friction of account creation. Instead of having users go through the multi-step Joomla process of registering a user account you can use SocialLogin. At the same time, the small handful of users with backend access is either using password login protected by Multi-factor Authentication, or login with passkeys. You only want to show SocialLogin buttons in the frontend for the benefit of your visitors, but not in the backend login where they are irrelevant and possibly confusing. Hence the need to only show the SocialLogin buttons in the frontend of the site.

Caveats

Before using this feature you should be aware of the following non-obvious caveats.

Potential for user lockout

If your site has both frontend and backend login pages, you have users who can access both the frontend and backend, and these users' only login method (or, at least, the only method they have noted down) is through SocialLogin then changing the SocialLogin method to only frontend or only backend will lock these users out of the other side of your site.

For example, let's say that you have an Administrator user who only logs into your site with Login with GitHub. If you edit the “Akeeba Social Login - GitHub integration” plugin and set “Login buttons can be shown in” to Frontend then this Administrator user will NOT be able to log into the backend of your site.

We always recommend using an alternative login method, on top of SocialLogin, for user account which fall under this use case. We strongly recommend using passkey logins as your alternative login method, as it is the only login method offered by core Joomla which is as strong as SocialLogin itself. Remember, your user account is only as strong as its weakest login method.

Joomla's Shared Sessions render this feature irrelevant

If you have enabled Joomla's Shared Sessions feature in its Global Configuration page then the “Login buttons can be shown in” feature in your SocialLogin plugins is largely irrelevant.

When Shared Sessions is enabled, users who have login access to both the frontend and the backend of your site will be logged into both the frontend and the backend of the site at the same time when they log into either side of your site.

For example, let's say that you have a Manager user who logs into your site with Login with Facebook. Let's also say that you have edited the “Akeeba Social Login - Facebook integration” plugin, setting its “Login buttons can be shown in” option to Frontend. This Manager user can go to the frontend of your site, log in with Facebook, then go to /administrator, and they find they are already logged into the backend of the site – even though you are not showing the Login with Facebook button in the backend login page.

Remember, the “Login buttons can be shown in” feature only controls the display of the login buttons. It cannot control what Joomla does with a logged in user. You CANNOT tell Joomla! to use Shared Sessions and not allow users to get logged into the backend of the site using SocialLogin in the frontend. It is simply NOT how Joomla! itself works.

This is neither a bug, nor something which can be addressed in any way. It is the way Joomla's Shared Sessions feature is designed to work. It does exactly the same thing with any login method e.g. password login, login with passkey, etc. If you do not want this behaviour you will have to disabled the Shared Sessions feature in Joomla's Global Configuration.

This is neither a security, nor a privacy feature

Hiding the login buttons from the frontend or backend of your site is NOT a security- or privacy-relevant feature. It's merely a preference.

To better understand the security and privacy considerations of SocialLogin as a whole please consult the Security and Privacy page. The key takeaways of that page are:

  • Logging in with SocialLogin is a strong form of authentication, far more secure than using a username and password.
  • Merely displaying the SocialLogin buttons does NOT have any privacy implications. They do NOT use privacy-invasive JavaScript libraries.

Therefore, there is no security or privacy reason for disabling SocialLogin plugins.

Also note that if you are worried about your social account being taken over, it merely means you are not following standard precautions such as using a strong password and a password manager, and two-factor / multi-factor authentication. Therefore, this is a non-argument.