New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Facebook Login integration for Joomla! #11778
Conversation
Fixed bug in rendering
Looking forward to testing this tomorrow On 24 August 2016 at 17:19, Nicholas K. Dionysopoulos <
Brian Teeman |
; Note : All ini files need to be saved as UTF-8 | ||
|
||
; Note 2: Do NOT alpha-sort the language keys. It makes translation far harder because it deprives the translator | ||
; of the string's context! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
roflmao
Thats something the PLT will have to decide on
Please, add also Twitter, Google, Live.com, Yahoo, Instagram, LinkedIn, WordPress, OK.ru, VK.com and Yandex |
This comment was marked as abuse.
This comment was marked as abuse.
My suggestion for the future! |
@joomla-ua READ THE FSCKING MANUAL. I already wrote that if this is accepted I will add Twitter, Google and maybe GitHub since I use them myself. Regarding your random list of services... Instagram uses Facebook (your IG account won't let you log in anywhere else). So, by accepting this PR you also get "Instagram authentication" covered. LOL! Yahoo... 1998 called and they want their social network back. They say that they support all the obsolete protocols, from OpenID to OAuth1. Just the fact that we removed BOTH of these integrations in Joomla 3 should tell you a lot about the state of Yahoo. Also, when was the last time you used them as your sole form of ID on the web? Around 2004? Yeah. Exactly. As far as I can tell Live.com (basically, Microsoft ID) does let you do that though they're not using OAuth2 so good luck to the poor guy who decides to implement that. They have my condolences. LinkedIn does offer that featurethrough OAuth2. However, I won't touch LinkedIn with a ten foot pole. Every time I do I start receiving 10x the amount of spam. Not to mention LinkedIn is bought by Microsoft so it's a matter of time until their own login method dies an undignified death in favour of the Windows Live ID monstrosity (all the more reason to not bother). As for WordPress... Read their API docs. Only available to log in to a specific WordPress.com blog or a JetPack-connected blog. /me dying from laughter. Regarding the Russian sites, why don't you find some Russian developer who's interested in this? I've tried using their APIs before but the English versions of their docs, um, leave a lot to be desired. Same goes for any other locale-specific social networks or fringe networks such as Ello. Keep in mind that if you implement Facebook (1 in 3 people on the planet), Google (1 in 6 people on the planet) and Twitter (1 in 20 people on the planet) authentication you've got a ridiculous percentage of Internet population covered. |
Re: Yandex - i am in contact with the lead developer of their browser so can make a connection if needed |
Good job! @nikosdion |
Tried to test. (as it cant be done using com_pachtester I downloaded the full zip from https://github.com/nikosdion/joomla-cms/archive/feature/social-login.zip After installation I went to the plugins but there is no Facebook authentication plugin - also checked je #__extensions db table Was able to install using discover
Missing from this is that you need the site to the whitelist I tried to set that as http://localhost/ but I still got the error This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11778. |
Getting this message after returning to my page:
|
Retested on a live domain and found two more issues
Failed to authenticate: PLG_AUTHENTICATION_FACEBOOK_ERROR_LOCAL_NOT_FOUND
|
I guess this should be tagged as New Feature |
IMHO JPlugin should be doing that automatically when the plugin object is instantiated. Since it doesn't developers end up calling loadLangauge on every event handler, making performance worse overall. Oh, well, that's the subject of another PR...
Joomla leaves user profile data behind when you delete a user record. This confused the login plugin.
Each time create a random password it will be different than the previous time. Obviously this is NOT what you want when you are, um, passing two supposedly _identical_ passwords to the Joomla user registration code. Oops!
@brianteeman and @Radek-Suski Thank you for the feedback. Everything fixed. Some notes:
Feel free to retest and provide further feedback. |
I followed the instructions very carefully that is exactly what I pasted Retesting with updated files in both localhost and live domain |
Hi @jeckodevelopment Thank you for the update! Whenever you have reached a decision please ping me so I can either finalize the details of this PR with you guys or decide on its future. |
This comment was marked as abuse.
This comment was marked as abuse.
@PhilETaylor you should look at: https://volunteer.joomla.org/leadership/production-leadership-team |
Nicholas, the ability to require admin approval is an intrinsic function On 28-Aug-16 10:22, Nicholas K. Dionysopoulos wrote:
|
This comment was marked as abuse.
This comment was marked as abuse.
@PhilETaylor thank you for reporting it. It's a "result" of the migration to the new Volunteers Portal. |
@N6REJ It depends. Self-registration has the email verification step to deter spammers. Obviously when your email is verified by someone you trust (Facebook) you don't want your user to go through that. Many of my clients have had issues with that kind of verification so they are now using the admin approval. In this case if the account is verified by Facebook they don't want to bother approving the account. In case they don't want ANYONE to subscribe without their explicit consent they shouldn't be using the admin approval feature, they should turn off user registration completely. So, the thing is, that it's NOT black and white. We can:
The point is that this is the kind of decision that needs to be made by a lead developer or addressed in a roadmap. Neither exists for Joomla. So I implemented by default what my clients expect which may or may not be what you expect. That's just ONE way to implement it. I need someone to take responsibility for such a decision. That someone cannot be me, I have no official position in Joomla. |
This comment was marked as abuse.
This comment was marked as abuse.
$db->qn('profile_key'), | ||
$db->qn('profile_value'), | ||
))->from($db->qn('#__user_profiles')) | ||
->where($db->qn('user_id') . ' = ' . $db->q((int) $userId)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I'm misinformed, But I thought int values shouldn't be quoted? Something about minor performance hits in MySQL due to string to int conversions and something about it causing issues with the non-MySQL databases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree. When I added the SQL query stuff to the Coding standards I wrote it with the expectation that we should always use quoting.
I'm more concerned about what @wilsonge mentioned about the quoting int values causing problems with the non-MySQL databases. (like I said, maybe I'm misinformed on the potential issue there)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @nikosdion , PLT finished the voting process about this PR and decided to not merge in the core this PR as it is now. We think that this PR could be divided into two different parts:
Can you help us splitting this PR as described? Thank you again! |
Can't say I'm surprised :D It was a moonshot and mostly sprang out from me scratching my own itch. I will update this PR to only contain part 1 (modifications in com_user and mod_login). I will also add the social login authentication plugin superclass in this, otherwise each social login plugin will need to duplicate a lot of code and that will come back to bite us with Joomla! 4 when we migrate all plugins to the new event system. Regarding part 2, I assume a core extensions is supposed to be developed in its own repo as demonstrated by com_weblinks. As such, I can't make a PR for that. At best I can provide my own repository with the social authentication plugins. I have two problems with this. For starters, as clearly demonstrated by com_weblinks, "core supported / official extensions" is where Joomla core extensions go to die. Users don't know where to find them and nobody seems to be interested to maintain them except as a demonstration of the new testing system. I actually want to provide social login plugins to help people with a REAL WORLD necessity. The second issue is that a "core supported / official extension" has absolutely no ownership. Even worse, it lacks a development vision and roadmap. The code committed will forever stay there until someone decides to fork it and maintain it as their own extension. Here's the thing: I am already writing this extension to scratch my own itch. Therefore it makes more sense for me to keep my code to myself and release the social plugins (for free) under my own brand, like I had been doing with the improved YubiKey and U2F two factor authentication plugins (for which I never got an official rejection but I did learn about it through hearsay and backchannels...). So, Part 2 is not going to happen. Sorry. |
There has actually been a really surprising ammount of activity in the web
links repo. Check it out I'm sure you will be as surprised as I was.
Also it might be easier to close this and create a new pr than to edit
everything here but that's your choice.
|
You never know in Joomla world. Extensions we built for the |
I did check the weblinks repository thoroughly. There is exactly ZERO activity pertaining to features. All of the activity has to do with using weblinks as a testbed for releasing core supported extensions and serving as the demonstration of using Codeception instead of straight PHPUnit as I explicitly stated in my previous reply. Therefore the reasonable conclusion is that core supported extensions is where core code goes to die (users don't know where it is, no feedback is taken, no features are developed). Basically, it's a code graveyard. Furthermore, we have to consider WHY we have core supported extensions. Instead of removing core components with limited use outright we are putting them in these code graveyards. Then again, what exactly is a "light" core? Sure enough, in 2016 the world usually doesn't need link directories or self-served banner ad networks as demonstrated by the lack of such extensions in the JED. The world DOES usually need social login plugins. The JED is rife with such extensions. The problem I tried to fix is that they indiscriminately pulled the entire FB API for PHP and all its dependencies (some 10Mb) to implement a feature that barely takes 500 lines of PHP code. Moreover, they required users to manually make template overrides and add code which is NOT user friendly. At least the second issue is going to be fixed by this PR. Speaking of a "light" core, I don't understand why on Earth we have the GMail authentication plugin –which doesn't work with GMail accounts that have 2FA enabled and relies on a soon to be obsolete authentication method implemented just in the plugin– but we don't want to have social login plugins which use the social network interface code in Joomla itself. If 3PD interop is considered heavy then all of the authentication plugins except "Authentication – Joomla" should be removed. Otherwise both the GMail plugin and the FB plugin should be included as they are essentially two of the same kind. Dunno, man, this is Joomla!. It doesn't have to make sense ¯_(ツ)_/¯ |
You can consider creating another PR for this.
We can create a repository under "Joomla Projects" and distribute the plugin as Official Extension. We have a dedicated category for this also in JED.
About this:
We're currently trying to face this issue. For the FB auth. plugin, you could be the perfect leader. |
That doesn't help matters any though if the repository is a big playground On Tuesday, September 6, 2016, Luca Marzo notifications@github.com wrote:
|
This PR is now closed (see #11778 (comment)) |
Bad call by PLT |
Is there any work at making this a standard joomla extension like Weblinks then? |
@joomlaproffs Yup!! The new repository is at https://github.com/joomla-extensions/facebook-auth I will start adding the code sometime today or tomorrow (just got back from my vacation due to getting married and going on a honeymoon so I am still catching up with work). |
@nikosdion with the final vote from the PLT, will you consider support for additional social networks (google, live.com, etc..)? |
@jscantrell Please refer to the dedicated repo: https://github.com/joomla-extensions/facebook-auth |
Yes, I do want to add more social login integrations. It will take me some time as I've been lately busy with life (getting married and moving) and everything had to be pushed back. My first line of business -after I get some work stuff sorted- is get the translations integration rolling on the repository, automate the build, coordinate with the PLT for dissemination and only then start adding features and improvements. It is a matter of learning to walk before running :) On Wed, Oct 26, 2016 at 9:03 AM +0300, "jscantrell" notifications@github.com wrote: @nikosdion with the final vote from the PLT, will you consider support for additional social networks (google, live.com, etc..)? — |
Congratulations! I saw you were recently married and had vacation. Very cool! Being new to Joomla (2 days) I just found there is a plugin "Authentication - Gmail". Do you have an opinion on this plugin and would /does it serve the same function and objectives that you would be including and coding for Google authentication? |
please keep support questions out of the bug tracker and move the discussion to the new repo if there are any questions about the new plugin or feature whishes. I'm locking here now as this is a closed Pull request. Thanks for understanding ;) |
Pull Request for Issue # .
Pinging @brianteeman @wilsonge @mbabker @PhilETaylor @crystalenka @rdeutz @Radek-Suski @SigsiuTrinity – I know you guys use Facebook and Joomla so please give it a spin if you have some time.
Summary of Changes
This PR adds the Authentication – Facebook plugin and necessary related changes.
This feature lets visitors log into your site using their Facebook account as long as the email address on their Facebook account matches the email they have on your site, or they have linked their Facebook account to your site. If they do not have an account on your site already it will be created automatically for them (you can disable that feature if you want).
Facebook login is ONLY available in the front-end of your site.
Why did I write this code?
(Truth be told, because I need this feature and all the integrations I found on the JED where bloated, badly written or just plain outdated.)
It's 2016. Most people expect to be able to login to any site using their Facebook, Google, Twitter or GitHub account. They are put off when they have to deal with Joomla's registration process and tend to miss the account verification email (because lots of spam filters mark Joomla's account verification email as spam, according to my experience).
This PR not only implements login by Facebook, it also puts the foundation for any kind of social login or single sign on service integration. I believe this is an important step towards modernizing Joomla's aging authentication infrastructure.
I only chose to implement Facebook login first –instead of GitHub, Twitter or whatever have you– because whether you like it or not Facebook is the most expansive social network on the planet right now. You can't beat the network effect. If this is approved I can try implementing more social logins (Google, Twitter and probably GitHub) as well.
Testing Instructions
Apply this PR. Follow the "How to link Facebook Login to your Joomla! site" section's instructions below to link Facebook to your Joomla! site. Go to the front-end of your site and make sure you can log in with Facebook.
Documentation Changes Required
The entire "How to link Facebook Login to your Joomla! site" is the documentation for this feature. The second paragraph of "Summary of Changes" can be used as an introductory text on that documentation page. Basically, you have to copy and paste. I did all the hard work for you ;)
Backwards compatibility
This PR impacts the way mod_login modules (front- and backend) and com_users (frontend) render their login pages.
If a template or site integrator has made overrides to these module and view templates they must update them to use this plugin. If they do not update them the plugin will not work but the site itself will still work, with regular authentication. Therefore, even though there's a minor b/c break it's not catastrophic and does NOT negatively affect existing extensions.
In other words, I made sure I didn't fsck up anybody's site.
Likewise for extensions which implement their own login screen, be it obviously login modules (duh!) or components (like Akeeba Subscriptions – I am creating more work for myself too, not just other developers). That's the first time since 2012 (when two factor authentication was introduced) that they need to do that. One update of your login screens every 4 years ain't that bad of a deal!
Translation impact
This PR introduces 15 new language strings, modifies 0 language strings and deletes 0 language strings.
Average translator time required: 10 minutes.
How to link Facebook Login to your Joomla! site
Setting things up on Facebook
Before you can use Facebook Login on your site you must create a Facebook App. Even though it sounds scary, a Facebook App is simply a way for you to get a set of access codes which let you identify your site on Facebook.
Start by visiting Facebook For Developer's site
Click the + Add New App button on the search bar. A popup opens.
In the popup enter the following information:
Now press the blue Create app ID button at the bottom right of the popup dialog.
In the Product Setup page click on the Get Started button next to the Facebook Login option. You will see the Facebook Login feature's Getting Started page.
Scroll all the way to the bottom of the page.
This is the important part. Find the Valid OAuth redirect URIs option. You will need to enter a URL in the form
http://www.example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
replacinghttp://www.example.com
with the real URL of your site.Keep in mind that Facebook is looking for an exact match of the URL being sent to it. Here are some gotchas regarding this requirement and how to deal with them:
http://
and anhttps://
URL you will need to enter both URL variations, with and without HTTPS. For examplehttp://www.example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
for the plain HTTP version of your site andhttps://www.example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
http://example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
,http://www.example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
andhttp://www.example.net/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
. Of course if you have HTTP and HTTPS on each domain you will need to also add the HTTPS versions of these three URLs for a total of six (6) URLs.http://www.example.com/joomla/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
http://localhost/joomla_test/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
Click on the blue Save Changes button to save the setup. Then click on the Settings link in the left hand sidebar.
Note down the App ID. This is the Facebook Application ID you need to enter to the plugin on your site.
We need one more piece of information. Inside the App Secret area click on the Show button. Facebook will ask you to enter your password.
After entering your password successfully you will see your App Secret. Note it down. This is the Facebook Application Secret you need to enter to the plugin on your site.
Tip: You can always view the App ID and App Secret at any time by going to https://developers.facebook.com/apps and selecting your site's Facebook App.
As an optional step, we recommend adding a logo to your Facebook App, typically the logo of your site. This will be shown to your site's visitors and it's useful to let them understand that the login request does come from your site. It must be 1024 x 1024 pixels square. Click inside the App Icon image to select a new file. Finally click on Save Changes to save the new logo.
Setting things up on Joomla
Login to your site's administrator backend and go to Extensions, Plugins. Find the plugin Authentication – Facebook.
Click on the plugin's name to edit its configuration.
Using the plugin
When the plugin is enabled, the Login module in the frontend of the site displays a Facebook Login button. Click on it.
The first time you do that, you'll be asked to grant permissions to the Facebook App to read your full name and email. After accepting that you are magically logged in!
Any subsequent click on the Facebook Login button on that site will magically log you into your Joomla site – as long as you are logged into Facebook.
Special considerations (READ ME BEFORE COMMENTING)
If you have not read this section and ask me something I have covered here I will reply to you with "RTFM". I know it's rude, but so is not reading the fine manual someone spent hours of his life writing only to ask what's already in it, you know?
Backend login
I decided against it. For starters, there are the security considerations below. However, the real show-stopper is the need for separate callback URLs in the front- and backend. In the frontend we can use com_ajax, exactly for the reason it's designed for.
In the backend we'd have to hardcode a feature in JApplicationSite to let certain callback URLs to be accessible without a user login. This could be easily abused by misguided developers to enable all sorts of callbacks in their components, all exposed from backend URLs. The security implications are chilling!
The other alternative is having the plugin initiate a backend login through a frontend URL. While technically possible, this is a violation of Joomla's security model of two separate and distinct applications. Even worse, this kind of code could set a precedent for unified front- and backend login or other frontend integrations which result in administrator backend access. This is EXTREMELY DANGEROUS and strongly advised AGAINST.
Furthermore, even if we did implement that in a secure way (e.g. using single use, very limited expiration time tokens stored in cookies), we face another issue. Redirecting from the frontend to the backend may trigger another security feature installed on many sites, a secret URL parameter which must be present in the URL the first time a session accesses the administrator folder. Think about Admin Tools' Secret URL Parameter feature, jSecure etc. Note however that a .htaccess password protection for the administrator folder is compatible with redirections or even Facebook's callback system itself (it takes place through browser redirections which work fine with a .htaccess password).
Bypassing TFA
By its nature, Facebook Login bypasses Two Factor Authentication. You are essentially outsourcing authentication to a third party system (Facebook) and trust its security model.
This cannot be worked around unless Joomla! implements real Two Factor Authentication. Right now we have second factor authentication which means that the user needs to provide their username (public information), password (first authentication factor) and secret code (second authentication factor). Basically, the secret key is a second, mandatory, password.
Real TFA is more like Google implements it. First you authenticate yourself with the minimum required information, e.g. a username and password, or a social login. At this point you have a captive login i.e. you have a logged in user but they have no permissions to carry out any action. In fact, trying to carry any action will bring them back to the captive login page where they have to supply their second authentication factor (security code, hardware token, SMS, ...). As we had discussed in 20-freaking-11 this would require a MAJOR b/c change in Joomla: JUser would need to report one of three states (guest, captive, logged in) instead of simply returning a boolean with
isGuest()
. We'd need to either removeisGuest()
to prevent old code from assuming that a non-guest user is logged in (or return false for captive log-ins) and at least add anisCaptive()
method to report captive logins. All the JUser authorization methods also need to change. Furthermore, JApplicationWeb would need to catch captive logins and only allow a specific com_users page to be displayed, much like we force the Joomla! login page in the backend when there's no logged in user. All of that is way out of scope of this PR and right into Joomla! 4 or Joomla! X territory.So trust me when I say that your only option is to disregard TFA with social logins, much like every existing implementation out there (and not just Joomla ones!) currently does.
Email spoofing
As it is right now, any Facebook account that matches the email address of a user account in Joomla will result in the user getting logged in as the matching user account. If you have a Joomla user account with the email
foo@example.com
and someone else creates a FB account with the emailfoo@example.com
they can login as you. This implies that they know your email address and you don't have a Facebook account under that email.There are two ways to deal with that.
Stolen Facebook accounts
Obviously, if someone steals your Facebook account credentials or otherwise manages to get hold of your Facebook account they can use it to log in to your site.
MITM attacks
Facebook Login hinges on the secure exchange of information from your site to Facebook (exchanging a temporary code with a Facebook token). This communication does take place through HTTPS and we do check the certificate's validity. A Man In The Middle attack would require not just DNS spoofing or an active MITM attack, but also a "perfect" forged certificate for facebook.com, signed by a commercial CA. This means that this kind of attack is only possible forvery sophisticated attackers or state actors.
No account unlinking
At this point there's no way to unlink your Facebook account from the site. Doing so would require two things:
So unless you want to make privacy paranoids happy there's no need to expend energy towards this.