Support

SocialLogin handles Joomla's onUserLoginButtons event. Joomla! uses this event to ask plugins to render additional login buttons. This is called by both the front- and back-end login modules which ship with Joomla!. Therefore, SocialLogin buttons will appear in both places.

The order of the SocialLogin buttons is the same as the order of the plugins in the sociallogin group. You can reorder plugins through System, Manage, Plugins in Joomla! as it's always been the case ever since it was still called Mambo. As for the overall ordering of buttons, Joomla! has a fixed position for the regular Login button. The other buttons are ordered based on the ordering of the system plugins which handle Joomla's onUserLoginButtons event.

Before we continue, just a few words about me. I have been working with site security, access control, and login technologies in Joomla! since it was called Mambo back in 2003. I am the developer who contributed things to Joomla like the original Two Factor Authentication, the modern Multi-factor Authentication, the WebAuth login plugin, Joomla Update and a lot more. SocialLogin didn't come out of left field. It was my attempt at making Joomla login more secure, not more convenient. The reason this is a separate product and not part of Joomla itself is that there's a long-standing rule in Joomla that no feature included in the core must be based on a third party service (with the only exception being reCAPTCHA as it predates this rule by several years).

So, let's get to the core of your question: security. I am glad you asked!

Using SocialLogin to log into your site is actually far less of a security risk than it is using a username and password. I know it sounds odd, but it actually is. All these social networks and login services implement and enforce two- and multi-factor authentication (2FA and MFA respectively). They also have the technology to detect anomalous logins and ask for re-authentication when something does not add up. Joomla! does have MFA – since I donated Akeeba LoginGuard to Joomla! since version 4.2 – but it's by default not enforced. Joomla! does not and will not have any anomalous login detection since this requires a lot of not-quite-privacy-friendly practices to be effective. Therefore, using SocialLogin is actually safer than a username and a password. Also do keep in mind that SocialLogin offers integration with more than just social networks, from your Google and Microsoft accounts, to Synology Single Sign-On service.

The security of SocialLogin-enabled logins is also impacted by your configuration. If you disallow automatic connection of existing user accounts to login providers you're very safe; only an admin account which explicitly chooses to link their third party login provider in advance would be able to make use of these buttons. If you prefer that not to happen, don't connect your privileged user accounts with a third party service and these buttons are effectively inert. Simple, innit? That said, I would recommend that in this case you use either WebAuthn to log into your site, or configure Joomla's MFA to be force-enabled for all privileged user accounts. Otherwise, you are forcing your privileged users to use something easily phishable and guessable (a username and password) instead of a robust, unspoofable, unguessable, and unphishable login method.

Moreover, I believe you misunderstand something fundamental. You cannot create a user with backend access privileges using SocialLogin unless you explicitly and intentionally misconfigure your site – but that would be stupid, and I don't think that my users are stupid. Even if you allow user creation via SocialLogin, trying to create a new site after visiting the backend merely create a new user in the user group you set up in the Users, Options page and which by default is Registered. Trying to login to the backend as a Registered user tells you that you don't have access, regardless of how you register that user (Joomla's user page, the backend Users component, SocialLogin, or anything else). SocialLogin is merely a login solution, it DOES NOT override Joomla's fundamental access control system which is based on users, groups, and permissions. Go ahead and try it.

Finally, let's talk about the obvious. Why do you have your site's admin page open to the world?! This has long been a solved problem. Use password protection in your administrator directory. You don't have to (and shouldn't) buy Admin Tools Pro just for this; ask your host, they probably have a very simple tool in their hosting control panel for you to do that. With this simple change you have effectively neutered any perceived problem.

I hope this helps :)

I should ignore the social login buttons on the admin access page cos social login do not have the privilege into the SuperUser user group which you need to get into the site administration pages

Not quite.

Are your admin users already linked to third party login services with SocialLogin?

• If yes: Use SocialLogin to log into your site, it's more secure.
• If not: You can't use SocialLogin, therefore the whole discussion is moot.

the suggestion you made in your marketing that it has the capability to spoof the Joomla identity of the site which seem too be a stretch by just renaming a syntax. I feel it'll take less than a minute to know its a Joomla site nonetheless, or what do you think?

The only "marketing" material I have is https://www.akeeba.com/products/admin-tools.html where I never make such a claim. Can you please show me where I made that claim?

Moreover, you also think about the generator meta tag, but that's completely tertiary. You really don't get it, do you? How does an attacker find your site? They use a search engine to look for common things that appear in Joomla! sites. Using the default generator meta tag is one of them, therefore changing that is recommended. If the attacker comes across your site a different way they will need to know if they have a chance to attack it. For that, they will need to enumerate your extensions and your extension and Joomla versions. The .htaccess Maker puts enough hurdles in place that makes this process very inaccurate. Ending up knowing that a site runs Joomla! version 3.9 to 5.0 is useless to an attacker and they are likely to not waste any time. Ending up knowing that a site runs Joomla! 4.0.1, on the other hand, gives the attacker an attack plan against known vulnerabilities which have since been fixed in Joomla!. So, no, saying that using security software to protect against fingerprinting (I don't know where the hell you got "spoof identity", that's a bullshit term nobody uses) is a good thing is absolutely not a stretch when you actually understand how sites get attacked.

does this protections blankets the inadvertent loop holes and vulnerabilities of other 3rd party extensions due to their weak coding practices etc. what specific feature of Admin Tool protects in such scenario

Yes, it does, to a great extent. No protection is absolute, though. If I had the magic way to make a blanket, absolutely perfect protection I would be selling it for billions of dollars to the FT 500 companies and governments, I would be sitting in a yacht sipping sugary drinks, and we would not be having this conversation. What Admin Tools does is put additional checks in place to prevent most common attacks against third party extensions and the core itself. Moreover, it mitigates the effect of the attack.

I will tell you two stories.

December 2015. A major SQL injection vulnerability existed in Joomla! and it was actively exploited in the wild. Unless, of course, you were using Admin Tools. Admin Tools' SQLiShield feature successfully caught and protected against this attack.

September 2023. A major flaw in AcyMailing which bypassed Joomla for file uploads results in thousands of sites being hacked, some of which belonging to the core Joomla! maintainers themselves. Unless, of course, you were using Admin Tools. Even though the attack vector was outside Admin Tools, the malicious uploaded file could not be executed thanks to the .htaccess Maker protections.

I've always likened security extensions to bulletproof vests. They will protect you against enemy fire to a reasonable degree. Now, if you get shot through the armhole, thrown a grenade, or shot with an M61 Vulcan you will die, no doubt about it. Security extensions will protect your site but if you are hacked from a script running outside of Joomla, because your entire server was compromised, or because you were targeted by an individual or organization with a great deal of resources you will be hacked. However, these are extremely unlikely scenarios. The vast majority of hacked sites are mundane, automated hacks perpetrated by lazy, boring criminals who want to make a quick buck sending spam and hosting malware. We don't live in a Hollywood technothriller; we live in the mundane reality, with its mundane dangers, with their mundane countermeasures. Security extensions like Admin Tools are these mundane countermeasures to these mundane dangers of our mundane reality.

As for which features in Admin Tools protect you, that would be all of them. That's the entire reason of its existence.

Other than this, you did not address my INSTAGRAM query :)

I don't know where you got that from. Definitely not my "marketing" material. Can you please show me where I made that claim?

If anything, there's this development ticket (https://github.com/akeeba/sociallogin/issues/5) which tells you why we could not implement a "Login with Instagram" back when Instagram and Facebook accounts were two separate things.

As things stand at the time of this writing, Meta no longer allows logging in with Instagram. They tell you to use Facebook login instead. In their Instagram API docs page https://developers.facebook.com/docs/instagram-api they explicitly state:

The API cannot access Instagram consumer accounts (i.e., non-Business or non-Creator Instagram accounts). If you are building an app for consumer users, use the Instagram Basic Display API instead.

However, when you go to the Instagram Basic Display API they tell you:

Authentication — Instagram Basic Display is not an authentication solution. Data returned by the API cannot be used to authenticate your app users or log them into your app. If you need an authentication solution we recommend using Facebook Login instead.

Facebook Login is already implemented in SocialLogin.

I am happy sharing my knowledge, especially on topics which are very counter-intuitive. After all, if nobody tells anybody anything how can anyone ever learn anything, right?

Hm, I might have left Twitter somewhere… but where? Can you send me a URL?

Regarding the expiration of the Temporary Super User account please remember that it requires the Pro version, and it is parsed at most once an hour.

Regarding access control, um, a Super User account by definition has unrestricted access. The Super User (core.admin) privilege is “god mode” in Joomla!. It overrides all other privilege settings. If you want limited access you need to create a user group, put the temporary account into that user group while removing it from the Super Users account, and remember to disable it manually because once it's no longer a Super User the Temp Super User feature stops taking care of that for you.

Thank you! The script refreshing the page had the wrong list of integrations.

I wonder why it is configurable in the core version without warning of its limitation.

Because you can still create a Super User account.

Button size is controlled by the login module / page, not our plugin. You can always do a template override and customise it to your heart's content!

Well, about that… If only it were that simple.

All of these companies are pretty strict on a. the logo to use; b. the color to use; c. the text to use; and d. the minimum whitespace to use in these login buttons. You will be surprised to find that the current buttons are actually just a hair smaller than what Facebook, Microsoft and a few others recommend as the minimum size. And, yes, they can totally blacklist you if you mess us their branding. Will they do that to some random site? Probably not. The question is, can you afford to take the risk?