Twitter dropping support for basic auth

Bug #627565 reported by Ken VanDine on 2010-08-31
162
This bug affects 35 people
Affects Status Importance Assigned to Milestone
Gwibber
High
Ken VanDine
gwibber (Fedora)
Won't Fix
Medium
gwibber (Ubuntu)
High
Unassigned
Lucid
Undecided
Unassigned
Maverick
High
Unassigned

Bug Description

Twitter have disabled their basic Authentication support which makes gwibber not to update your streams. if you are facing this problem under Ubuntu 10.04 or 10.10 please do the following and add twitter account again. things will work fine. The solution to this problem will soon be made available to all users through updates but for the time being.

sudo add-apt-repository ppa:ubuntu-desktop/ppa ; sudo apt-get update ;sudo apt-get upgrade

Victor Vargas (kamus) wrote :

Please Ken fix this :)

Changed in gwibber (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Omer Akram (om26er) wrote :

Ken is the Hero. latest version of gwibber is up in the desktop team's ppa. testing is welcome

Changed in gwibber (Ubuntu):
assignee: nobody → Ken VanDine (ken-vandine)
importance: Medium → High

Description of problem:
It isn't getting my twitter timeline

Version-Release number of selected component (if applicable):
[Ankur@070905042 ~]$ rpm -q pino
pino-0.2.11-1.fc13.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Add a twitter account to pino
2.select the twitter account and let pino get your timeline
3.

Actual results:
It gets stuck on "Getting updates".

Expected results:
Should get and update latest timeline

Additional info:
X

Problem is twitter has stopped supporting basic authentication. OAuth is not supported in pino yet. It is scheduled for pino 0.3 http://pino-app.appspot.com/index

So I guess it's time to push a snapshot in updates-testing and see how it goes...

Omer Akram (om26er) on 2010-09-01
description: updated
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gwibber - 2.31.91-0ubuntu1

---------------
gwibber (2.31.91-0ubuntu1) maverick; urgency=low

  * New upstream release
    - Port twitter service to OAuth, basic auth is no longer
      supported (LP: #627565)
    - Delay setting the position of the vertical splitter
    - Fix PerformOp for single operation, including delete and
      like (LP: #616798)
    - Make the string for the Translate action i18n
      friendly (Vadim Rutkovsky)
    - Convert identi.ca groups (!) to hashtags (#) for re-denting if
      global_retweet is true (Vadim Rutkovsky) (LP: #539786)
    - Handle null responses gracefully (James Ogley) (LP: #623309)
    - recognize valid unicode URLs (LP: #333390)
    - Don't crash if there is an invalid value for a preference (LP: #623335)
  * debian/gwibber-service.install
    - Install files needed for twitter oauth
 -- Ken VanDine <email address hidden> Mon, 23 Aug 2010 23:35:05 -0400

Changed in gwibber (Ubuntu):
status: Triaged → Fix Released
Changed in gwibber:
importance: Undecided → High
status: New → Fix Released
Changed in gwibber (Ubuntu):
status: Fix Released → Triaged
assignee: Ken VanDine (ken-vandine) → nobody
Changed in gwibber:
assignee: nobody → Ken VanDine (ken-vandine)

Accepted gwibber into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gwibber (Ubuntu Lucid):
status: New → Fix Committed
tags: added: verification-needed
Omer Akram (om26er) wrote :

Fixed in Maverick already.

Changed in gwibber (Ubuntu):
status: Triaged → Fix Released
pwaring (launchpad-pwaring) wrote :

Is testing in a VM good enough (I don't want to enable proposed on my main machine)? If so I will give it a whirl tonight on lucid.

Jean-Baptiste Lallement (jibel) wrote :

pwaring, yes testing in a VM is good enough, as long as it is an update to date lucid and it's not and hardware related issue. Any feedback is welcomed!

I'm now running version 2.31.92 from the daily build and Twitter is now working fine.
Thanks Ken!

It worked for the daily build, it also worked for version 2.30.2~bzr742. When I saw the Twitter authentication page, I smiled :-)

Jacob Helwig (jhelwig) wrote :

The package in lucid-proposed fixes this bug for me.

Martin Pitt (pitti) on 2010-09-02
tags: added: verification-done
removed: verification-needed
pwaring (launchpad-pwaring) wrote :

Confirmed working here on a clean (updated to latest packages) installation of Lucid in a VM.

I am not sure picking up a random snapshot of the day is really the answer to this. Does the latest HEAD support this at all? I have this discussed it with upstream and primary maintainer for Fedora here and it appears there is bad news

http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/2

See the section on FOSS clients.

Rahul, surely I'd expect the maintainer and upstream to work more or less together on the thing in order to select an appropriate snapshot in time.

However, I also read the ars article today and it seems to be trickier than I'd expected, very sad.

In light of this:

"""Most FOSS client developers have simply chosen to embed their keys in their source code with the hope that Twitter won't notice. I was about to give up on Gwibber, but Canonical intervened on my behalf (special thanks to Ken VanDine) and negotiated a compromise with Twitter that will allow Gwibber to continue using the service."""

Can Fedora, Red Hat or someone else attempt to do the same for pino, after all, it's our default client.

Appropriate snapshot is an option if Pino has support for it and what if someone reads the source and sends it to Twitter? Twitter is going to block it as per their utterly broken scheme. As far as negotiating an exception, please bring it up to desktop or devel list. Maybe we can get one.

sam tygier (samtygier) wrote :

one comment on the new UI. it is easy to miss the save button after twitter accepts the usename/password. if you don't press save then the authentication is lost. this was also noted on http://ubuntuforums.org/showthread.php?t=1565315

Bilal Akhtar (bilalakhtar) wrote :

Tested the thing in -proposed and maverick on 2 different sys, works well, no problems.

Ken VanDine (ken-vandine) wrote :

We know about the problem with people missing the "Save" button, it will be addressed in a future version.

Colin Watson (cjwatson) wrote :

I'm waiving the normal seven-day aging period on this bug because of Twitter being broken for everyone following the oauthpocalypse. Please shout if it's made anything worse.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gwibber - 2.30.2-0ubuntu1

---------------
gwibber (2.30.2-0ubuntu1) lucid-proposed; urgency=low

   * New upstream release
    - Port twitter service to OAuth, basic auth is no longer
      supported (LP: #627565)
    - Remove the tr.im urlshortener, the service is closed (LP: #583316)
    - Better handling of unexpect results from twitter and
      identi.ca (LP: #613420)
    - Better handling of error responses from twitter, should log more
      and traceback less (LP: #613420)
  * debian/gwibber-service.install
    - Install files needed for twitter oauth
  * debian/control
    - Added build dep for python-oauth, twitter now uses it
 -- Ken VanDine <email address hidden> Wed, 01 Sep 2010 12:05:54 -0400

Changed in gwibber (Ubuntu Lucid):
status: Fix Committed → Fix Released

In Facebook when we write on the wall of a person, it should be showing the
name of both *'the person writing comment'* and *'the person on which the
comment is written'*. Presently it is only showing the name of* person
writing comment*. It could not be judged that to whom is he/she is talking
unless you open it on web browser.

It should show both names on the gwibber.

On Fri, Sep 3, 2010 at 7:59 PM, Ken VanDine <email address hidden>wrote:

> We know about the problem with people missing the "Save" button, it will
> be addressed in a future version.
>
> --
> Twitter dropping support for basic auth
> https://bugs.launchpad.net/bugs/627565
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (588563).
>

pwaring (launchpad-pwaring) wrote :

A minor comment on upgrading - I could not add any more Twitter accounts (or authorise my existing accounts) after an upgrade on Lucid. Restarting my machine fixed the problem - perhaps gwibber-service was not restarted automatically after the package had been upgraded?

Marking as a blocker, as it's involves shipping a desktop app that does not work for one of it's main uses.

I'll update pino to the 0.3 snapshot this weekend for test purpose. Not sure if pino 0.3 can be finally released before F14 final freeze date.

Did you talk to upstream about picking up a snapshot and when the 0.3 release is scheduled?

(In reply to comment #9)
> Did you talk to upstream about picking up a snapshot and when the 0.3 release
> is scheduled?

I'll update pino 0.3 snapshot[1] in rawhide soon for test purpose if no one objects.

No sure if upstream has a such schedule currently since pino 0.3 is still under pre-alpha stage. I'll ask upstream for a release plan after pino 0.3 alpha is released.

[1]http://bitbucket.org/troorl/pino3

Is there any chance at all to backport the fix? (I'm guessing the port to oauth is nontrivial, so, no.)

(In reply to comment #11)
> Is there any chance at all to backport the fix? (I'm guessing the port to oauth
> is nontrivial, so, no.)

I don't know vala at all, but it seems it's almost impossible to backport features from pino 0.3 to pino 0.2 (from upstream pino 0.3 is a completely new project).

Ok. Please update rawhide to 0.3 snapshot so that we can test if it is in a shippable state for Fedora 14. Otherwise we will have to switch to Gwibber or not ship with a microblogging client. Inform upstream if necessary of our deadlines.

In my case pino stalls out on 'connecting.' Furthermore it refuses to exit, it has to be killed.

I'm trying out the 0.3 build on f14 beta
http://koji.fedoraproject.org/koji/buildinfo?buildID=195712

I note that my account info did not migrate to the new version, which is fair I suppose given the oauth thing. OAUTH validation isn't working (redirects to twitter, paste the code, click verify, ... nothing), but what should I expect from a random unreleased koji build ;)

(In reply to comment #13)
> Ok. Please update rawhide to 0.3 snapshot so that we can test if it is in a
> shippable state for Fedora 14. Otherwise we will have to switch to Gwibber or
> not ship with a microblogging client. Inform upstream if necessary of our
> deadlines.

It seems pino 0.3 can't be released before F14 final, I think we can ship Gwibber as the default twitter client for F14 (maybe we should split mx into more packages to save space on livecd).

Is there a problem shipping the snapshot? Is it unusable?

Hmm, well I tried pino-0.3-0.1.20100915hg.fc14 again and this time it managed to authenticate via OAUTH.

It is however very clunky and lacking functionality. Three of the four menu headings (Pino, View, and Help) are empty lists. Edit has one entry, New Account, which has sub-entries for identica and twitter.

I just tried to tweet with it and it doesn't seem to be working. There is a "sending statuses" notice that just keeps spinning.

The account pane on the side and a number of context menus that don't seem to actually function. In particular the "Settings" entry does nothing.

All in all, not a good user experience. I'm not a big fan of Gwibber, but it's better than this.

This was discussed at the blocker review meeting of 2010-10-01. It was accepted as a blocker under the criterion "All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items". Desktop team, please either ensure pino is fixed somehow for final, or pick a twitter client that works, or don't ship one; the fix doesn't have to be to make pino work, any of the above is fine.

*** Bug 638984 has been marked as a duplicate of this bug. ***

I reported the same bug yesterday yesterday not realising one had already been filed (obviously my Bugzilla search-fu could do with an update). It hasn't been noted here yet, but pino-0.2.11-1 doesn't work with identi.ca either. Thought I'd mention it as I just saw a note on the desktop list from Jesse Keating saying:

  "From what I understand, pino also works with identi.ca,
  and there is no issues with the current version in F14 for
  doing that."

Alas, there is. I've tried numerous times since F14 Alpha was released and pino has never gotten past the "updating..." phase for either Twitter or identi.ca.

After seeing a report on the desktop mailing list that pino works fine with identi.ca I ran some more tests, deleting "~/.cache/pino" and "~/.config/pino" after each test so I was starting from a clean state. I was wrong: pino does indeed work fine if you're only using identi.ca, or if you make sure to not add a Twitter account *before* adding an identi.ca account.

I'll leave pino running with both accounts to see if it'll eventually hang as it was doing before.

Upgraded my desktop from F13 to F14 Beta and Pino works flawlessly with identi.ca. I also have configured there a twitter account which simply does not receive updates.

That being said, if we know the current snapshot doesn't work with twitter, is it worth shipping it over the 0.2.x stable version?

(In reply to comment #23)
> That being said, if we know the current snapshot doesn't work with twitter, is
> it worth shipping it over the 0.2.x stable version?

The current pino 0.3 can support Twitter's OAuth security system, but the snapshot is not even an alpha release. So I think it's not appropriate to ship pino 0.3 for F14 currently(we can push pino 0.3 as an update when possible), the pino 0.2 in Fedora can only log in identi.ca since 2010.9.1.

I don't think we should be shipping pino (either version) as is. Folks will be looking for a twitter client and pino is going to give them a bad impression of the distro in that department.

The gwibber in F14 has been working fine for me this past week.

 I sent comment on Desktop mailing list, but to clarify for users of this bug, the Gwibber 2.33 client in F13 updates-testing works fine with OAuth for Twitter, and identi.ca support.

 And the user interface update supports Twitter lists, and general other features Pino lacks.

 Original reason for removing Gwibber and moving to Pino was based on earlier couchdb and erland dependancies (20MB+ of dendancies). This no longer the case with the SQLite backend.

 Is there any logic in trying to push a broken Pino, or leaving the install with no client at all, when Gwibber is known to work?

Seconded. From a user experience point of view, pino makes Fedora look bad. Gwibber works and has a more polished UI, whereas pino's UI is less polished and more importantly only works currently if you (a) only use identi.ca or (b) don't add a Twitter account before adding an identi.ca account.

As the gwibber maintainer, I'd be okay with that.

it seems like we decided definitely not to ship pino, only decision left is whether to replace it with gwibber or replace it with a release note saying to try gwibber. :) can team please implement this in time for TC1 build on tuesday? Thanks!

pino has been made optional in comps. No other changes have been made at this point. Here is mclasen's most recent statement about it:

http://lists.fedoraproject.org/pipermail/desktop/2010-October/006574.html

If that's to be interpreted as the Desktop SIG's answer on what to do with the Live image, then it means the latter of comment #30's two choices. And I presume that would remove this bug from the F14Blocker list.

I suspect people will be rather disappointed if there is not a Twitter/Identi.ca client in the default install, but I'll defer to the Desktop SIG.

next steps
   1) add release note documenting the change (Fedora docs team), then ...
   2) confirm release note and remove from F14Blocker list (anyone)

(In reply to comment #33)
> next steps
> 1) add release note documenting the change (Fedora docs team), then ...
> 2) confirm release note and remove from F14Blocker list (anyone)

I'll be drafting this later this afternoon and will post the text so everyone will be able to make suggestions.

As soon as the comps change is made this ceases to be a blocker, we do not cover documentation in the blocker process at present.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

spot: the desktop team's decision was made on the basis that it was too late to safely switch to gwibber and ensure there were no problems with its integration; they recognized that a working twitter client would be the *ideal* solution, but in practice it wasn't considered safe enough to switch at this late stage.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The current state is: Pino 0.2 (current in F14) has connectivity issues with Twitter. There's an (alpha/beta) version out of Pino 3, which can work with Twitter, but it's still very rough, as mentioned in Comment 17. (even the 3-JAN-2011 release suffers most of these issues).

I'd very much propose to switch to a mature and stable microblogging client for F15: obvious candidates would be Gwibber or Turpial.

Can we get input from the Desktop Team? At this point in time, switching to Gwibber for F15 would be still possible...
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I think this bug can be closed by now with Gwibber as working alternative?

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Changed in gwibber (Fedora):
importance: Unknown → Medium
status: Unknown → 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

Remote bug watches

Bug watches keep track of this bug in other bug trackers.