Opening facebook "Success" page in external browser

Bug #1180297 reported by Iain Lane
870
This bug affects 264 people
Affects Status Importance Assigned to Milestone
Online Accounts: Sign-on UI
Medium
Alberto Mardegan
Ubuntu UX
High
Katie Taylor
account-plugins (Ubuntu)
High
Alberto Mardegan
Quantal
High
Unassigned
Raring
High
Unassigned
signon-ui (Ubuntu)
Undecided
Unassigned
Quantal
Undecided
Unassigned
Raring
Undecided
Unassigned

Bug Description

[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.

Related branches

Revision history for this message
Iain Lane (laney) wrote :
Revision history for this message
Alberto Mardegan (mardy) wrote :

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

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

Changed in gnome-control-center-signon (Ubuntu):
status: New → Confirmed
assignee: nobody → Alberto Mardegan (mardy)
Revision history for this message
Stefan (sschweizer) wrote :

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

Revision history for this message
Alberto Mardegan (mardy) wrote :

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.

Revision history for this message
BsL (bsl-bsl) wrote :

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.

Revision history for this message
Fabio Duran Verdugo (fabioduran) wrote :

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

Revision history for this message
Aprianto Nursetiawan (noersetiawan) wrote :

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

Revision history for this message
BlueCase (bluecase) wrote :

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

Revision history for this message
Damon Hartman (area51pilot) wrote :

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.

Revision history for this message
Dabo Ross (daboross) wrote :

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?

Revision history for this message
Sadi Yumuşak (sa-yu) wrote :

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.

Revision history for this message
BsL (bsl-bsl) wrote :

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>

Revision history for this message
Alberto Mardegan (mardy) wrote :

@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).

Revision history for this message
Fidel Leon (fidel-ea3lf) wrote :

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

Revision history for this message
Andrea Pivetta (vanpivix) wrote :

Comment #10 worked for me too.

Revision history for this message
AliNâ (alinajafi) wrote :

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?

Revision history for this message
Alberto Mardegan (mardy) wrote :

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.

Revision history for this message
PatrikG (patrik-grundstrom) wrote :

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

Revision history for this message
Franko Burolo (fburolo) wrote :

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...

Revision history for this message
Chris Guidry (chris-theguidrys) wrote :

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

Revision history for this message
Franko Burolo (fburolo) wrote :

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...

Changed in gnome-control-center-signon (Ubuntu):
importance: Undecided → High
Revision history for this message
Bruce (brunces) wrote :

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

Revision history for this message
Miroslav Hadzhiev (xtigyro) wrote :

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

Revision history for this message
Patrick (patrickstar777) wrote :

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

Revision history for this message
bisi (fox-hole-bisi) wrote :

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.")

Revision history for this message
Jerome Rasky (jyrome-112) wrote :

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

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

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.

Revision history for this message
Samizdata (samizdata) wrote :

Comment 4 was a fix for me, for now.

Revision history for this message
Samizdata (samizdata) wrote :

Whoops, Raring 64-bit.

Revision history for this message
Alberto Mardegan (mardy) wrote :

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.

Changed in gnome-control-center-signon:
status: New → Confirmed
affects: gnome-control-center-signon (Ubuntu) → account-plugins (Ubuntu)
affects: gnome-control-center-signon → account-plugins
Changed in account-plugins (Ubuntu Raring):
importance: Undecided → High
status: New → Confirmed
milestone: none → raring-updates
Revision history for this message
tateeskew (tate-eskew) wrote :

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>

tateeskew (tate-eskew)
Changed in account-plugins (Ubuntu Quantal):
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in account-plugins (Ubuntu):
status: Confirmed → Fix Released
description: updated
Changed in account-plugins (Ubuntu Quantal):
importance: Undecided → High
milestone: none → quantal-updates
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

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!

Changed in account-plugins (Ubuntu Quantal):
status: Confirmed → Fix Committed
tags: added: verification-needed
Changed in account-plugins (Ubuntu Raring):
status: Confirmed → Fix Committed
Revision history for this message
Brian Murray (brian-murray) wrote :

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!

Revision history for this message
Jason Robinson (jaywink) wrote :

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.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Christian Perreault (christian-perreault-2) wrote :

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.

Revision history for this message
Hansen (moteprime) wrote :

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

Revision history for this message
Никола Павловић (nikola825) wrote :

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

Revision history for this message
Alberto Mardegan (mardy) wrote :

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

Revision history for this message
Noah Young (noahpyoung) wrote :

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

Revision history for this message
Vincent (vinnl) wrote :

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.

Revision history for this message
Alberto Mardegan (mardy) wrote :

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

Revision history for this message
Robin (robingape) wrote :

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

tags: added: quantal
Katie Taylor (katie-t)
no longer affects: ayatana-design
Changed in ubuntu-ux:
status: New → Confirmed
Revision history for this message
Katie Taylor (katie-t) wrote :

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.

Changed in ubuntu-ux:
status: Confirmed → Triaged
importance: Undecided → High
John Lea (johnlea)
description: updated
Katie Taylor (katie-t)
description: updated
Revision history for this message
John Green (john-thegreens) wrote :

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

Revision history for this message
Alberto Mardegan (mardy) wrote :

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).

Revision history for this message
Katie Taylor (katie-t) wrote :

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.

description: updated
Revision history for this message
Alberto Mardegan (mardy) wrote :

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

Changed in signon-ui:
assignee: nobody → Alberto Mardegan (mardy)
status: New → Confirmed
status: Confirmed → In Progress
importance: Undecided → Medium
no longer affects: account-plugins
Katie Taylor (katie-t)
Changed in ubuntu-ux:
assignee: nobody → Katie Taylor (katie-t)
Revision history for this message
Katie Taylor (katie-t) wrote :

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 :)

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in signon-ui:
status: In Progress → Fix Committed
Revision history for this message
Sebastian (sebastianhaselbeck) wrote :

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

Revision history for this message
Colin Watson (cjwatson) wrote : Update Released

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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in account-plugins (Ubuntu Raring):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in account-plugins (Ubuntu Quantal):
status: Fix Committed → Fix Released
Revision history for this message
saimon samir (bmw-saimon) wrote :

hi

John Lea (johnlea)
Changed in ubuntu-ux:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in signon-ui (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in signon-ui (Ubuntu Quantal):
status: New → Confirmed
Changed in signon-ui (Ubuntu Raring):
status: New → Confirmed
Revision history for this message
Rolf Leggewie (r0lf) wrote :

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".

Changed in signon-ui (Ubuntu Quantal):
status: Confirmed → Won't Fix
Revision history for this message
Rolf Leggewie (r0lf) wrote :

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".

Changed in signon-ui (Ubuntu Raring):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions