[#11778] - Facebook Login integration for Joomla!
- Closed
- 17 Sep 2016
- Medium
- Build: staging
- # 11778
- Diff
- nikosdion:feature/social-login
- Success continuous-integration/drone the build was successful Details
- Failure continuous-integration/travis-ci/pr The Travis CI build failed Details
User tests: Successful: Unsuccessful:
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:
- Display name: When the visitors to your site click on Login with Facebook they will be told that an app by that name requires permission to see their full name and email address. It's a good idea to put the name of your site here.
- Contact email: This is the email Facebook will use to contact you whenever there is an important reason. This is NOT visible to the visitors of your site. Enter the email address of the person who will be managing this site.
- Category: Choose the category that best matches your Facebook App. "Apps for Pages" seems to be the most fitting category for a Facebook App used for site login.
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 replacing http://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:
- If you have a site which is accessible through BOTH an
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=rawfor the plain HTTP version of your site andhttps://www.example.com/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw - If your site is accessible through multiple domain / subdomain names you will need to enter the URLs for each and every domain / subdomain. For example, if your site is available through example.com (without www in front!), www.example.com (with www in front) and www.example.net (different domain name, note it's .net instead of .com!) you will need to enter THREE URLs there,
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=rawandhttp://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. - If your site is installed in a subdirectory you must use the full path to your site. For example, if your site is installed in http://www.example.com/joomla the URL you need to enter here is
http://www.example.com/joomla/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw - You CAN set up localhost URLs here to test this feature on your local development site. For example, if your site is installed in http://localhost/joomla_test you need to enter here is
http://localhost/joomla_test/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw - Your site MUST NOT convert these callback URLs to SEF URLs. The plugin itself is designed to never do that but some overzealous SEF / SEO plugins may end up doing that. If you get a message from Facebook about the callback URL not being allowed try disabling all SEO / SEF plugins on your site. If that helped please ask its developer to add an exception for com_ajax URLs (URLs to com_ajax must NEVER be translated to SEF format).
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.
- Facebook Application ID The App ID you noted down when setting up the application (see the previous section). This is required for the plugin to work.
- Facebook Application ID The App Secret you noted down when setting up the application (see the previous section). This is required for the plugin to work.
- Create new user accounts? When enabled, a new Joomla! user account will be created for user who do not already have a Joomla! user account with the same email as their Facebook account's email address. New user accounts will NOT be created if user registration is disabled in the Users component. If user registration is set to Self or Admin an account verification email will be sent out to the user or the administrators (respectively). However, no email will be sent and the account will be immediately activated when the Facebook account is reported as "verified". A "verified" Facebook account means that the Facebook user has already verified their email address or phone number with Facebook. As such, there is no need to verify that person's email address again.
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 remove isGuest() 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 an isCaptive() 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 email foo@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.
- Only allow verified accounts to log in. Only persons who have verified their phone or email address with Facebook will be able to use the Facebook Login feature. This MAY cause some problems with users who haven't bothered to do that. I don't know how common an unverified account is.
- Require manually linking the Facebook account with the Joomla user account. That would happen either implicitly (a new user account is created through the Facebook Login feature) or explicitly (the user links their Facebook account with the site). The latter requires writing a user plugin to handle that case.
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:
- A user plugin to let you link / unlink a Facebook account to your user account. I didn't write one because at this point the PR is speculative, there's no Joomla roadmap and I don't know if I have wasted my time or if people are REALLY interested in my code :p
- Implementing yet another callback in the plugin which would let Facebook ping us when a user revokes our application's privileges inside Facebook itself ("uninstall" the app from their profile). I think that's a useless feature since even if he does and we do nothing about it (the code as is) any further logins will simply display the app authorization page again. No big deal.
So unless you want to make privacy paranoids happy there's no need to expend energy towards this.
Votes
joomla-cms-bot
- | Category | ⇒ | Administration Components Language & Strings Modules Templates (admin) Front End Libraries Plugins Templates (site) |
| Status | New | ⇒ | Pending |
| Labels |
Added:
?
?
|
||
Please, add also Twitter, Google, Live.com, Yahoo, Instagram, LinkedIn, WordPress, OK.ru, VK.com and Yandex
@joomla-ua tl;dr? - READ what @nikosdion wrote!
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.
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
Looking forward to have it working on my website.
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
So I guess it is missing from the installation sql
Was able to install using discover
You CAN set up localhost URLs here to test this feature on your local development site. For example, if your site is installed in http://localhost/joomla_test you need to enter here is http://localhost/joomla_test/index.php?option=com_ajax&group=authentication&plugin=facebook&format=raw
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:
Fatal error: Call to a member function register() on a non-object in /var/www/radek/plugins/authentication/facebook/facebook.php on line 306
Retested on a live domain and found two more issues
- If you forget that you have to enable "Allow User Registration" and try to use the facebook login for the first time you will get an error with a missing string
Failed to authenticate: PLG_AUTHENTICATION_FACEBOOK_ERROR_LOCAL_NOT_FOUND
- After remembering to enable "Allow User Registration" and trying to use the facebook login for the first time I get a fatal error
Fatal error: Call to a member function register() on boolean in /srv/users/serverpilot/apps/eupt715ps016social0dev/public/plugins/authentication/facebook/facebook.php on line 306
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11778.
I guess this should be tagged as New Feature
| Labels |
Added:
?
|
||
@brianteeman and @Radek-Suski Thank you for the feedback. Everything fixed. Some notes:
- Missing installation SQL files added
-
@brianteeman URL Error: this means that you skipped a step in the documentation. Go to https://developers.facebook.com/apps, click on your app, click on Facebook Login from the left hand sidebar, find the "Valid OAuth redirect URIs" entry in the main area and enter
http://localhost/index.php?option=com_ajax&group=authentication&plugin=facebook&format=rawassuming that your test Joomla site is installed at http://localhost and NOT any subdirectory. Please note that you need to paste the entire URL. I did exactly that and it worked. Also note that this will ONLY work if your Facebook app is still in development mode (you have not made it public through the App Review page). - Fatal error registering user: sorry, my bad, I mistyped JPATH_ADMINISTRATOR instead of JPATH_SITE. I also fixed a related issue.
- Untranslated language strings: the string is there but Joomla doesn't load it by default. Made sure Joomla now does load the language file.
Feel free to retest and provide further feedback.
I followed the instructions very carefully that is exactly what I pasted
http://i.tee.mn/vMHU.png
Retesting with updated files in both localhost and live domain
Retested and all the issues I reported before are now resolved
Moving on to new issues - tested using both the login module and the component
1. On login the url becomes
http://localhost/joomla-cms-feature-social-login/#=
or
http://localhost/joomla-cms-feature-social-login/index.php/article-category-list#=
note the #=
Redirect on login
Set a menu item to be redirected to on login in the module (or component if you are testing that) and check that it works correctly with the regular login
Test again with the facebook login and you are logged in but you are not redirected.Failure to login successfully
Try to login using facebook with new registration disabled and you get redirected to the home page with the error message. You should remain on the same page as you are on when you attempted to login
Email Notification
After successfuly logging in with facebook for the first time and my account being created on the site I received an email as follows
To: brian@teeman.net
Subject: COM_USERS_EMAIL_ACCOUNT_DETAILS
Date: Thu, 25 Aug 2016 12:16:49 +0100
From: facebook a@example.com
Message-ID: 845883dbb5752baae6c3dbe83d44e8e5@localhost
X-Mailer: PHPMailer 5.2.16 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8COM_USERS_EMAIL_REGISTERED_BODY
For reference if it helps these are the options I have set in com_users which apart from allowing registration are the defaults
Can confirm what @brianteeman wrote. Worked fine, just the email is not translated. Not sure if it is related to this plugin directly though
I would test - but I'm currently searching for dinosaurs in Eden :-(
Sent from my iPhone
On 25 Aug 2016, at 13:11, Radek Suski notifications@github.com wrote:
Can confirm what @brianteeman wrote. Worked fine, just the email is not translated. Not sure if it is related to this plugin directly though
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
note the #=
Added by Facebook. I don't think I can do anything about it.Redirect on login
I don't think it can be implemented without some really bad code but I'll try my best.Failure to login successfully
Directly related to the previous issue.
Regarding the untranslated email: what the heck, Joomla?!! Whoever has been involved in writing the com_users component over the years must have not ever heard of why MVC was invented 50 years ago (reusability of code). Apparently the user registration model does not load the language strings, even though it's supposed to be the ONE place where all user registrations go through (as opposed to every developer implementing their own crap). Argh!
Time to introduce more technical debt, er, "workarounds".
That's what I suspected :P
note the #=
I wasnt going to mention that at all until I thought it might be related to
the other issues. As it is its not anything to bother about - the url
redirect on login is though
All fixed. It was slightly more complicated than it should have been and I ended up storing the redirection URLs in the session.
Another change I just made is about security. As I had mentioned in "Email spoofing" it was possible for a very naughty boy to register a (fake) Facebook account under your email and use it to impersonate you on your site – as long as you don't already have a FB account under that name. I changed that by enabling this feature only for verified Facebook accounts i.e. accounts that we already know have verified their email / phone number with Facebook. So, if you have an unverified Facebook account under the same email address as your Joomla user account you will NOT be able to log in. However, if you have a verified Facebook account you will be able to log in.
Feel free to test and provide feedback.
All works fine for me now. Email looks good (username + pass) delivered.
Only tested the redirect on login this time
The behaviour is different between the joomla login and the facebook login
You will see in this video that although the correct page is loaded the url is different
We know how users will scream about duplicate content ;)
Testing the email notifcation
It works now but I think it should use a different string for accounts created this way
Now
You may now log in to http://localhost/joomla-cms-feature-social-login/ using the following username and password:
Suggestion
You may now log in to http://localhost/joomla-cms-feature-social-login/ with your facebook identity or using the following username and password:
Or something like that
PHP Warning when creating a user
When you login for the first time and a user is created there is a PHP Warning
PHP Warning: in_array() expects parameter 2 to be array, integer given in /plugins/authentication/facebook/facebook.php on line 185
The only thing I can't and won't do is have a different email message for the created user account for three important reasons:
Makes maintaining the CMS hard(er). Changing the language strings used requires duplicating the entire
UsersModelRegistrationclass inside the Facebook login plugin. Having done that in Akeeba Subscriptions (because at the time I had to also support Joomla! 1.5, not because I am a masochist) I can tell you that in the long run it will lead to inconsistencies and hard to trace bugs, including possible security issues (remember how we added a switch regarding sending the password by email?)You are opening the door to inconsistencies. Once you let third parties change the language keys used during the user subscription flow you are making it impossible to support users having a question regarding those emails. Simply put, you will never know if the user overrode the language string or a misguided developer is using his own language key (or hardcoded string). Also linked to the previous issue, you add a massive inertia to changing anything related to the user registration as it now affects all 3PDs, not just the core (therefore you can only touch it in major version every 2-5 years!).
DRY. Remember what I wrote four hours ago? There should really be a singular point where user accounts are created because of the previous 2 reasons. Right now we can use the core as an example of consistent usage of the same code to create user accounts. If we break that rule we legitimise the worst practice of 3PDs and make it impossible to change anything related to user registration without having everyone rightfully complaining that we're breaking backwards compatibility.
So, just no. Don't make me break Joomla!.
PHP notice and url issues are now fixed
In com_users there is an option for New User Authentication with values, None, Self and Administrator
Creating an account with this facebook authentication plugin completely ignores those. I can kind of see why it ignores the Self option but not the administrator
When I try to login/create a new user via the FB-button it redirects me to Facebook where I have to confirm and after clicking YES it sends me back to my site. But without successful login and this error message is displayed: Failed to authenticate: You do not have an account on our site that corresponds to this Facebook account.
Strange, because looking as superadmin to the backend, I can see that a new account was created/enabled/activated with the correct data. And when I click again in the frontend the Facebook login button, I am logged in.
When I log out and then login again, everything works fine.
Hm, I can login as a blocked user.
I confirm @christainhent findings. If you try to use the facebook login with a blocked account it still works :(
This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/11778.
Thank you, guys! I fixed that and also trying to login when your Joomla! account is not yet verified.
I also refactored the code to make it more abstract and moved half of it in an abstract superclass we can use for other social network authentication / single sign on plugins. It also moves all of the login code in one place which makes it easier to manage in future versions of Joomla.
I can confirm that I can no longer login if an admin has blocked my account. ;)
I can still log in if the user options says that an admin must approve all accounts :(
At some point in the last set of tests I got a PHP notice
[26-Aug-2016 20:49:44 Europe/London] PHP Notice: Uninitialized string offset: 0 in /Applications/MAMP/htdocs/joomla-cms-feature-social-login/libraries/joomla/application/web.php on line 507
To make travis happy here: https://travis-ci.org/joomla/joomla-cms/jobs/155375822#L1085
FILE: ...uild/joomla/joomla-cms/libraries/cms/authentication/field/interface.php
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
16 | ERROR | @since tag comment indented incorrectly; expected 2 spaces but
| | found 3
66 | ERROR | File must end with a newline character
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: .../build/joomla/joomla-cms/libraries/cms/plugin/authentication/social.php
--------------------------------------------------------------------------------
FOUND 13 ERROR(S) AFFECTING 11 LINE(S)
--------------------------------------------------------------------------------
21 | ERROR | Doc comment for "$loginUrl" missing
21 | ERROR | Doc comment for "$failureUrl" missing
35 | ERROR | Expected 2 spaces after the longest variable name
37 | ERROR | Expected 2 spaces after the longest type
50 | ERROR | Missing comment for param "$fullName" at position 1
71 | ERROR | Expected 2 spaces after the longest variable name
90 | ERROR | Instanciating new classes without parameters does not require
| | brackets.
146 | ERROR | Expected 2 spaces after the longest type
146 | ERROR | Expected 2 spaces after the longest variable name
208 | ERROR | Doc comment for "$user" missing
226 | ERROR | Instanciating new classes without parameters does not require
| | brackets.
258 | ERROR | Missing @return tag in function comment
271 | ERROR | File must end with a newline character
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: /home/travis/build/joomla/joomla-cms/libraries/joomla/user/helper.php
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
301 | ERROR | Expected 2 spaces after the longest type
301 | ERROR | Expected 2 spaces after the longest variable name
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: ...is/build/joomla/joomla-cms/plugins/authentication/facebook/facebook.php
--------------------------------------------------------------------------------
FOUND 39 ERROR(S) AND 1 WARNING(S) AFFECTING 32 LINE(S)
--------------------------------------------------------------------------------
26 | ERROR | Expected 3 spaces before variable type
26 | ERROR | Missing comment for param "$subject" at position 1
27 | ERROR | Expected 3 spaces before variable type
27 | ERROR | Missing comment for param "$config" at position 2
40 | ERROR | Doc comment for "$loginUrl" missing
40 | ERROR | Doc comment for "$failureUrl" missing
120 | ERROR | Instanciating new classes without parameters does not require
| | brackets.
188 | WARNING | Line exceeds 150 characters; contains 168 characters
256 | ERROR | Opening parenthesis of a multi-line function call must be the
| | last content on the line
260 | ERROR | Closing parenthesis of a multi-line function call must be on a
| | line by itself
273 | ERROR | Expected 2 spaces after the longest variable name
274 | ERROR | Expected 2 spaces after the longest type
285 | ERROR | Tabs must be used to indent lines; spaces are not allowed
285 | ERROR | Opening parenthesis of a multi-line function call must be the
| | last content on the line
286 | ERROR | Tabs must be used to indent lines; spaces are not allowed
287 | ERROR | Tabs must be used to indent lines; spaces are not allowed
288 | ERROR | Tabs must be used to indent lines; spaces are not allowed
288 | ERROR | Closing parenthesis of a multi-line function call must be on a
| | line by itself
289 | ERROR | Tabs must be used to indent lines; spaces are not allowed
290 | ERROR | Tabs must be used to indent lines; spaces are not allowed
291 | ERROR | Tabs must be used to indent lines; spaces are not allowed
308 | ERROR | Tabs must be used to indent lines; spaces are not allowed
309 | ERROR | Tabs must be used to indent lines; spaces are not allowed
310 | ERROR | Tabs must be used to indent lines; spaces are not allowed
311 | ERROR | Tabs must be used to indent lines; spaces are not allowed
331 | ERROR | Tabs must be used to indent lines; spaces are not allowed
332 | ERROR | Tabs must be used to indent lines; spaces are not allowed
333 | ERROR | Tabs must be used to indent lines; spaces are not allowed
334 | ERROR | Tabs must be used to indent lines; spaces are not allowed
343 | ERROR | Expected 2 spaces after the longest type
343 | ERROR | Expected 2 spaces after the longest variable name
353 | ERROR | Tabs must be used to indent lines; spaces are not allowed
353 | ERROR | Opening parenthesis of a multi-line function call must be the
| | last content on the line
354 | ERROR | Tabs must be used to indent lines; spaces are not allowed
355 | ERROR | Tabs must be used to indent lines; spaces are not allowed
355 | ERROR | Closing parenthesis of a multi-line function call must be on a
| | line by itself
356 | ERROR | Tabs must be used to indent lines; spaces are not allowed
357 | ERROR | Tabs must be used to indent lines; spaces are not allowed
377 | ERROR | Tabs must be used to indent lines; spaces are not allowed
378 | ERROR | Tabs must be used to indent lines; spaces are not allowed
--------------------------------------------------------------------------------
UPGRADE TO PHP_CODESNIFFER 2.0 TO FIX ERRORS AUTOMATICALLY
--------------------------------------------------------------------------------
FILE: ...ld/joomla/joomla-cms/plugins/authentication/facebook/field/facebook.php
--------------------------------------------------------------------------------
FOUND 4 ERROR(S) AFFECTING 4 LINE(S)
--------------------------------------------------------------------------------
38 | ERROR | Missing function doc comment
43 | ERROR | Missing function doc comment
48 | ERROR | Missing function doc comment
56 | ERROR | Missing function doc comment
--------------------------------------------------------------------------------
I can still log in if the user options says that an admin must approve all accounts :(
As I said, if you have a verified Facebook account you are exempt from the account activation process. I did ask for feedback about that feature (and a few other points) but nobody cared to discuss. Also note that without a Joomla roadmap, a feature RFC process or a lead architect / lead developer to talk to I can only pluck hair out of my butt about what would be deemed best for Joomla!. I'm not going to change that feature until I get any feedback from the PLT. FWIW it's just a 3 liner if-block.
Regarding the PHP notice, it comes from a part of Joomla! I have not touched. Since that part of Joomla (the web application superclass) is out of scope to this PR I won't touch it.
@PhilETaylor I am not going to bother with that until someone can tell me if this is going to be included or not and whether any functional changes are required. I am basically not putting any more time in it unless I get any kind of feedback (or there's a genuine bug).
Hey @nikosdion , just to inform you that PLT is currently voting about the inclusion of your PR.
We'll come back to you as soon as we have the result of the vote.
Thank you for your effort.
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.
Ironic then that the PLT has no members haha https://volunteer.joomla.org/teams/production-leadership-team#members
@PhilETaylor you should look at: https://volunteer.joomla.org/leadership/production-leadership-team
Nicholas, the ability to require admin approval is an intrinsic function
of J! user registration imo. Ergo I think the FB plugin should follow
that flow. It's fine that it automates everything else, but it still
needs to follow the rules so to speak.
Bear
On 28-Aug-16 10:22, Nicholas K. Dionysopoulos wrote:
Hi @jeckodevelopment https://github.com/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.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#11778 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABw66fMwUN3nPFgXe7Rh_8V2xMbmYEGiks5qkaengaJpZM4JsMRx.
@PhilETaylor you should look at: https://volunteer.joomla.org/leadership/production-leadership-team
I just used google... like anyone else would and got a blank team..
@PhilETaylor thank you for reporting it. It's a "result" of the migration to the new Volunteers Portal.
Opened an issue about that. ;)
@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:
- ignore the Joomla! account verification setting for verified FB accounts
- ignore Facebook's verification flag
- ignore Joomla! account verification for verified FB accounts ONLY for self-registration
- ignore Joomla! account verification for verified FB accounts ONLY for admin approval
- something else?
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.
@nikosdion could this not be yet another "option" that can be set by the site admin?
Hi @nikosdion ,
first of all PLT wants to thank you for the valuable contribution.
PLT finished the voting process about this PR and decided to not merge in the core this PR as it is now.
Actually PLT wants to keep the Joomla! CMS core lightweight and clean.
We think that this PR could be divided into two different parts:
- Modifications/Improvements to com_user and mod_logins : PLT wants to merge this part into the core.
- Facebook Authentication : we would to have this as an authentication plugin. Our proposal is to provide this as an official extension (like Weblinks or the other decoupled extensions).
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 joomla.org websites and have posted on GitHub without "official" releases seem to be getting attention and use from community members.
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 ¯_(ツ)_/¯
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.
You can consider creating another PR for this.
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.
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.
This should fix the issue you was talking about:
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.
About this:
The second issue is that a "core supported / official extension" has absolutely no ownership. Even worse, it lacks a development vision and roadmap.
We're currently trying to face this issue. For the FB auth. plugin, you could be the perfect leader.
Unfortunately it's not so easy as it may appear, find leaders that have a clear vision and a roadmap.
That doesn't help matters any though if the repository is a big playground
(the repo in project space). Even Install from Web's repos are severely
ignored, and that has core integrations!
On Tuesday, September 6, 2016, Luca Marzo notifications@github.com wrote:
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.You can consider creating another PR for this.
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.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.
This should fix the issue you was talking about: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.About this:
The second issue is that a "core supported / official extension" has
absolutely no ownership. Even worse, it lacks a development vision and
roadmap.We're currently trying to face this issue. For the FB auth. plugin, you
could be the perfect leader.
Unfortunately it's not so easy as it may appear, find leaders that have a
clear vision and a roadmap.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#11778 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoTqoUFS3Ure9PwM_112FheuMEG9Wks5qnZHtgaJpZM4JsMRx
.
This PR is now closed (see #11778 (comment))
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-09-17 06:58:48 |
| Closed_By | ⇒ | brianteeman |
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..)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
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 ;)
| Labels |
Removed:
?
|
||
Looking forward to testing this tomorrow
On 24 August 2016 at 17:19, Nicholas K. Dionysopoulos <
notifications@github.com> wrote:
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/