Opening facebook "Success" page in external browser

[Iain Lane]

[Test Case]
1. Open Online Accounts
2. Click "Add account…"
3. Select "Facebook"
4. Observe that a facebook login form loads in the control center panel instead of an external browser, with a security warning.

[Regression Potential] None: the current situation is completely broken as long as facebook does this http redirect during auth. This fix just allows that http request.

-----------------------------
Desired resolution:

Users should be warned about security passively with a notice of the security status on the page, rather than interrupting the page-flow.

The security status should be displayed as an icon & text. The best place for the status is to the bottom left of the frame, balancing the legal notice link. Alternatively the status could be displayed at the bottom of the web-authentication area.
- The icon should be similar to the icon used in the browser (browser phablet app).
- The text should be a description of the page security.

[Alberto Mardegan (mardy)]

It's exactly the same issue as bug #1132030.

I opened a ticked with Facebook: https://developers.facebook.com/bugs/449221825171392

[Stefan (sschweizer)]

Is here a workaround for this to use the facebook account in the meantime?

[Alberto Mardegan (mardy)]

Workaround: edit the /usr/share/accounts/providers/facebook.provider file and add the following line along the other settings:

<setting name="AllowedSchemes" type="as">['https','http']</setting>

Then restart the session and it should work.
Note however that this exposes your desktop to some security risks, so please use it only if you are connected to a trusted network.

[BsL (bsl-bsl)]

I tried the above workaround, but couldn't get it to work for me. Also tried adding the suggested line in the "telepathy" group of /usr/share/accounts/services/facebook-im.service.

[Fabio Duran Verdugo (fabioduran)]

The comment 4 work for me! add the line and restart all account services process.

[Aprianto Nursetiawan (noersetiawan)]

Where to put the line in comment #4? Is it in the last line of facebook.provider?

[BlueCase (bluecase)]

Can confirm. Workaround of Post #4 working.
But as I wrote in Bug #1132030. For this kind of problem signon-ui must be able to catch the failure and show the user that the service try to redirect them to a non secure URL. Perhaps with a exeption request.
Only to open a web page with a Securtiy Warning Message which isn't understandable is not enough.
I know.. This is a failure of Facebook but it wasn't the first and will be also not last time where that happen.

regards,
Marco

[Damon Hartman (area51pilot)]

Post #4 does not work for me. Added setting info and restarted system but no change in status of issue.

Also, if I try to add ANY account to the Online Accounts after Empathy is up and running ... the online-accounts window opens then closes, sometimes giving me a crash error.

[Dabo Ross (daboross)]

Changing

<?xml version="1.0" encoding="UTF-8"?>
<provider id="facebook">
  <name>Facebook</name>
  <icon>facebook</icon>
  <translations>account-plugins</translations>
  <domains>.*facebook\.com</domains>
  <plugin>generic-oauth</plugin>

  <template>
    <group name="auth">
      <setting name="method">oauth2</setting>
      <setting name="mechanism">user_agent</setting>
      <group name="oauth2">
        <group name="user_agent">
          <setting name="Host">www.facebook.com</setting>
          <setting name="AuthPath">/dialog/oauth</setting>
          <setting name="RedirectUri">https://www.facebook.com/connect/login_success.html</setting>
          <setting name="Display">popup</setting>
          <setting type="as" name="Scope">['publish_stream','read_stream','status_update','user_photos','friends_photos','xmpp_login']</setting>
          <setting name="ClientId">302061903208115</setting>
        </group>
      </group>
    </group>
  </template>
</provider>

to

<?xml version="1.0" encoding="UTF-8"?>
<provider id="facebook">
  <name>Facebook</name>
  <icon>facebook</icon>
  <translations>account-plugins</translations>
  <domains>.*facebook\.com</domains>
  <plugin>generic-oauth</plugin>

  <template>
    <group name="auth">
      <setting name="method">oauth2</setting>
      <setting name="mechanism">user_agent</setting>
      <group name="oauth2">
        <group name="user_agent">
          <setting name="Host">www.facebook.com</setting>
          <setting name="AuthPath">/dialog/oauth</setting>
          <setting name="RedirectUri">https://www.facebook.com/connect/login_success.html</setting>
          <setting name="Display">popup</setting>
          <setting type="as" name="Scope">['publish_stream','read_stream','status_update','user_photos','friends_photos','xmpp_login']</setting>
          <setting name="ClientId">302061903208115</setting>
          <setting type="as" name="AllowedSchemes">['https','http']</setting>
        </group>
      </group>
    </group>
  </template>
</provider>

in /usr/share/accounts/providers/facebook.provider

worked for me to fix it.

Everyone who this isn't working for, are you adding the
          <setting type="as" name="AllowedSchemes">['https','http']</setting>
inside the
        </group>
      </group>
    </group>
  </template>
</provider>
of the xml document?

[Sadi Yumuşak (sa-yu)]

Inserting the line suggested worked for me.
But can we perhaps reduce the security risks mentioned if we only include 'https' and leave out 'http'?
I always login to facebook using https.

[BsL (bsl-bsl)]

Thanks #10 Dabo, I now understand why adding the line doesn't work for me, as my /usr/share/accounts/providers/facebook.provider contains only this:

<?xml version="1.0" encoding="UTF-8" ?>
<provider id="facebook">
  <name>Facebook</name>
  <icon>facebook</icon>
  <domains>.*facebook\.com</domains>
</provider>

[Alberto Mardegan (mardy)]

@Sadi: that's exactly the problem: by default (if that "AllowedSchemes" option is not used) we only use HTTPs. But with facebook this doesn't work, because even if you start authenticating to facebook over HTTPs, at a certain point you get redirected to a plain HTTP page (if only for a short time).

[Fidel Leon (fidel-ea3lf)]

Comment #10 workaround worked for me in a fresh, clean, Lubuntu 13.10 install.

[Andrea Pivetta (vanpivix)]

Comment #10 worked for me too.

[Ali Najafi (alinajafi)]

The suggested workaround in comment #4 works for me too on a 32-bit Ubuntu 13.04.
But is it safe to use http in this case?

[Alberto Mardegan (mardy)]

Ali, it's safe if you can trust the network. If you are at home, using your wireless network, and you trust that your internet provider won't try to steal your facebook identity, then it's fine. If you cannot trust your internet provider, or you are using some open wireless network which you don't manage yourself, then don't use this trick.

[PatrikG (patrik-grundstrom)]

Tried comment #10 on Ubuntu 12.10. Didn't work.

[Franko Burolo (fburolo)]

The workaround worked for me too, on Raring 64. Now the only problem are the security concerns. My computer is a laptop, and I sometimes change locations where I connect from. It is mostly at the apartment where I stay during studies, at my faculty, at the hackerplace I sometimes frequent, and at my parent's home. I guess I can trust those 4, more-less, BUT...

[Chris Guidry (chris-theguidrys)]

Workaround #4 confirmed. (13.04 x86_64, Chrome, Gnome 3.8.2 from gnome3-staging PPA)

[Franko Burolo (fburolo)]

I have tried to remove "http", and leave only the https scheme, as suggested by sa-yu in comment #11, but only AFTER I already logged in. So far (some two days) I have no problems. I will see what happens next time I well have to re-authorize it...

[Bruce (brunces)]

Workaround (comment #10) did not work for me either. Same as comment #18, Ubuntu 12.10, 64-bit.

[Miroslav Hadzhiev (xtigyro)]

The bug occurs on a fresh Ubuntu 13.04 64-bit installation with all the current updates applied.

[Patrick (patrickstar777)]

with me the bug occurred out of the blue, on a raring 64 system. fix from comment #10 worked for me. thank you :)

[bisi (fox-hole-bisi)]

I tried comment #4...I might have done it pasted the code into the wrong part of the script or something, but it broke my online accounts. When I click on "Facebook", the window cycles immediately back to the same condition as when I opened it and I receive a notification ("Some or all of your applications can no longer access Onlive Accounts.")

[Jerome Rasky (jyrome-112)]

Fix from comment #10 worked on 64-bit raring system.

[Marc Deslauriers (mdeslaur)]

While allowing http is less than ideal, since we're using a webkit engine riddled with security issues, I suppose it's the only thing we can do to allow facebook to work for now. Other providers are currently using http, so it's not as if we're reducing overall security.

[Samizdata (samizdata)]

Comment 4 was a fix for me, for now.

[Samizdata (samizdata)]

Whoops, Raring 64-bit.

[Alberto Mardegan (mardy)]

Adding the design team: I was wondering if we could handle these errors in a more flexible way, by asking the user whether he wants to continue with the unsecure authentication or cancel (similarly to what browsers do).

Maybe before redirecting the user to an unsecure page we could show a simple page with some explanatory text ("You are about to access a web site through an unsecure connection; any information you will enter through these pages might be stolen by a malicious user") and a "Continue" button. A "Cancel" button might not be necessary since we already have it on top of the web frame.

[tateeskew (tate-eskew)]

This also affects 12.10.

The temp fix above does not work with 12.10, though. The /usr/share/accounts/providers/facebook.provider file contains only this:

<?xml version="1.0" encoding="UTF-8" ?>
<provider id="facebook">
  <name>Facebook</name>
  <icon>facebook</icon>
  <domains>.*facebook\.com</domains>
</provider>

[Launchpad Janitor (janitor)]

This bug was fixed in the package account-plugins - 0.11-0ubuntu1

---------------
account-plugins (0.11-0ubuntu1) saucy; urgency=low

  * New upstream release
    - Allow Facebook to connect via plain HTTP to work around a bug in
      in facebook's auth process where it redirects to http (LP: #1180297)
 -- Ken VanDine <email address hidden> Tue, 04 Jun 2013 09:56:17 -0400

[Brian Murray (brian-murray)]

Hello Iain, or anyone else affected,

Accepted account-plugins into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/account-plugins/0.8-0ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Iain, or anyone else affected,

Accepted account-plugins into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/account-plugins/0.10bzr13.03.26-0ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jason Robinson (jaywink)]

Awesome Brian.

Tested on Raring (3.9.4-030904-generic) with account-plugin-facebook out of proposed at version 0.10bzr13.03.26-0ubuntu1.1

Can confirm successfully added a Facebook account via Online Accounts as it should go, previously could not do it before the update.

[Christian Perreault (christian-perreault-2)]

Same thing as Jason: Tested on Raring (3.8.0-23-generic) with account-plugin-facebook proposed version 0.10bzr13.03.26-0ubuntu1.1 and that works!

I successfully added a Facebook account, I can see the contacts and I successfully chatted with one!

I hope that helps, since it is my first contribution on Launchpad.

[Hansen (moteprime)]

Raring Desktop 64.
Can also confirm proposed package 0.10bzr13.03.26-0ubuntu1.1 fixed the bug.

[Никола Павловић (nikola825)]

Is the fix secure, does it use HTTPS or HTTP? I connect to varius wifi hostspots and i need an encrypted connection.

[Alberto Mardegan (mardy)]

@nikola825: unfortunately the fix is a workaround: we allow HTTP.

[Noah Young (noahpyoung)]

Quantal 64
The fix in Comment #10 did not work for me, but using the fix in quantal-proposed worked.

[Vincent (vinnl)]

Proposed version 3.6.2-1ubuntu1 works for me. The already entered Facebook account still said it could not authenticate, re-authenticating worked. Would be nice, though, if this would start using HTTPS again once Facebook fixes the issue on their side, and perhaps just fail gracefully (i.e. do not open the browser, allow the user to continue acknowledging risk) until then.

[Alberto Mardegan (mardy)]

@Vincent: yes, we are working on that solution.

[Robin (robingape)]

Updated Quantal installation to version 0.8-0ubuntu2.2, and it worked instantly! Many thanks for that.

[Katie Taylor (katie-t)]

I think users should be warned about security passively with a notice of the security status on the page, rather than interrupting the page-flow.

My suggestion is to display the status as an icon & text. The best place for the status is probably to the bottom left of the frame, balancing the legal notice link.
- The icon should be similar to the icon used in the browser (browser phablet app).
- The text should be a description of the page security.

[John Green (john-thegreens)]

 0.8-0ubuntu2.2 in Quantal fixed this for me too :-)

[Alberto Mardegan (mardy)]

I'm attaching an example of how the security warning could look like. It uses the "security-low" icon from the theme (it's a standard freedesktop icon name, mentioned here: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html).

[Katie Taylor (katie-t)]

The position of the warning is great.
But, the icon could be better - I'll see if we have one.
And I think the text could use a bit of explanation - what does insecure mean? A definition could be put in a tool-tip.

[Alberto Mardegan (mardy)]

Hi Katie, I'm attaching another screenshot. This one looks much better, IMHO :-)
Meanwhile I'll be working on the help page.

[Katie Taylor (katie-t)]

Looks great!
One adjustment: I think the 16px icon would look better. Its designed to fit with that size text.
If you would like me to read over the help page, give me a ping :)

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:signon-ui at revision 106, scheduled for release in signon-ui, milestone 0.12

[Sebastian (sebastianhaselbeck)]

hoping for the fix to land soon. this new window with that warning opens like every other minute ...

[Colin Watson (cjwatson)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package account-plugins - 0.10bzr13.03.26-0ubuntu1.1

---------------
account-plugins (0.10bzr13.03.26-0ubuntu1.1) raring-proposed; urgency=low

  * Allow Facebook to connect via plain HTTP to work around a bug in
    in facebook's auth process where it redirects to http (LP: #1180297)
 -- Ken VanDine <email address hidden> Tue, 04 Jun 2013 11:28:49 -0400

[Launchpad Janitor (janitor)]

This bug was fixed in the package account-plugins - 0.8-0ubuntu2.2

---------------
account-plugins (0.8-0ubuntu2.2) quantal-proposed; urgency=low

  * debian/patches/lp_1180297.patch
    - Allow Facebook to connect via plain HTTP to work around a bug in
      in facebook's auth process where it redirects to http (LP: #1180297)

account-plugins (0.8-0ubuntu2.1) quantal-proposed; urgency=low

  * debian/patches/lp_1029289.patch
    - Use the web-authentication as described in
      https://developers.google.com/accounts/docs/OAuth2 (LP: #1029289)
  * debian/rules
    - Include Google Client Secret.
 -- Ken VanDine <email address hidden> Tue, 04 Jun 2013 11:25:54 -0400

[saimon samir (bmw-saimon)]

hi

[Launchpad Janitor (janitor)]

This bug was fixed in the package signon-ui - 0.15daily13.06.25-0ubuntu1

---------------
signon-ui (0.15daily13.06.25-0ubuntu1) saucy; urgency=low

  [ Alberto Mardegan ]
  * Show a warning message when authenticating with plain
    HTTP. (LP: #1180297).

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 106
 -- Ubuntu daily release <email address hidden> Tue, 25 Jun 2013 04:31:06 +0000

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rolf Leggewie (r0lf)]

quantal has seen the end of its life and is no longer receiving any updates. Marking the quantal task for this ticket as "Won't Fix".

[Rolf Leggewie (r0lf)]

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".