Bug 201985 - widget-microblogging doesn't work behind a proxy
Summary: widget-microblogging doesn't work behind a proxy
Status: RESOLVED DUPLICATE of bug 155707
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: http (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-30 11:49 UTC by Marcos David
Modified: 2011-03-01 23:26 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos David 2009-07-30 11:49:37 UTC
Version:            (using KDE 4.2.98)
Installed from:    SuSE RPMs

I use my laptop in to different places, at work (behind an authenticating  proxy) and at home (without proxy). In my workplace the microblogging widget doesn't show any info.
But at home it work correctly.

Since there are a number of applets that don't work correctly behind an authenticating proxy, I supposed this is just one of those cases.
Comment 1 Aaron J. Seigo 2009-08-03 08:43:16 UTC
the microblogging plasmoid uses KIO for its networking. so you have to set up the proxy properly in system settings for it to work in the microblog plasmoid or any other plasma widget, really.
Comment 2 Marcos David 2009-08-03 10:09:29 UTC
Sorry, but It really doesn't work. I have proxy settings configured correctly.
But the micro-blogging applet never asks for a username/password to access either the proxy, or kdewallet.
Comment 3 Marcos David 2009-08-06 12:35:41 UTC
Hi again,
This seems to be affecting the opendesktop applet. Is there anyway I can debug this issue?
Can it just be a text rendering issue with the applets?
Comment 4 Aaron J. Seigo 2009-08-06 12:58:24 UTC
as i noted, if the proxy settings are correct it will affect all plasma widgets that do networking as they all use KIO for their network needs. i don't see how this could be related to text rendering (since you said they work when you go home, right?). i still think there's something not "right" with the proxy settings. 

does web browsing work in konqueror?
Comment 5 Marcos David 2009-08-06 14:16:30 UTC
Hi, 
yes, web browsing works in konqueror.
Here is a list of applets that i tested and their status:
Web browser applet OK
Comic strip OK
Remember the milk OK
News is OK
Photo of the day is OK

Translatoid NOK - No translation
simple weather forescast NOK - I got a "network unreacheable"
Dictonary NOK - No results
Comment 6 Aaron J. Seigo 2009-08-06 15:03:51 UTC
> Translatoid NOK - No translation

it uses kio:

    m_job = KIO::http_post(url, postData, KIO::HideProgressInfo);

> simple weather forescast NOK - I got a "network unreacheable"

third party add-on.

> Dictonary NOK - No results

it uses QTcpSocket directly; that's a bug. fix upcoming.
Comment 7 Aaron J. Seigo 2009-08-06 15:04:30 UTC
SVN commit 1007893 by aseigo:

use KTcpSocket as it has proxy support
CCBUG:201985


 M  +3 -2      dictengine.cpp  
 M  +2 -2      dictengine.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1007893
Comment 8 Marcos David 2009-08-06 16:21:10 UTC
Hi,
I did a little more debbuging, and went to identi.ca site with konqueror.
I open the main page, but I can't login!
Message from konqueror:
The requested operation could not be completed
Connection to Server Refused
Details of the Request:
URL: https://identi.ca/main/login
Protocol: https
Date and Time: Thursday 06 August 2009 15:15
Additional Information: identi.ca: Unknown error
Description:
The server identi.ca refused to allow this computer to make a connection.

The thing is, I tried it with our internal mail server which also uses https, and it gave me the same message, even after adding it to the proxy exclusions list.

But gmail in https works fine.

Is this somehow related to konqueror's handling of https behind an authenticated proxy?
Comment 9 Marcos David 2009-08-06 23:29:54 UTC
I am trying this from home again, without proxy, everything works.
This must be a bug in the internet access layer.
Comment 10 Aaron J. Seigo 2009-08-06 23:50:24 UTC
> Is this somehow related to konqueror's handling of https behind an
> authenticated proxy?

it will be related to either kio_http or KIO itself, which is why i asked about konqueror. so .. it's a bug lower in the stack than plasma. let's reassign this bad boy, and CC someone in the know (though he's on vacation atm and won't be back for a few more days yet)
Comment 11 Marcos David 2009-08-07 10:20:57 UTC
I'm going on vacation too.
So for the next couple of weeks I won't be able to test any patches.
Comment 12 Marcos David 2010-05-14 12:51:56 UTC
Hi again,
I re-tested everything on KDE 4.4.3.
Everything is ok except for the dictonary which still doesn't return any result.
Comment 13 Marcos David 2010-08-16 12:42:55 UTC
Hi,

I'm using KDE 4.5 and I'm having issues with the social desktop thing...
It isn't working behind the proxy....
I can't seem to be able to pass the "Test Login" in the "Manage Social Desktop Provider" tab in SystemSettings.
How can I debug this?
Comment 14 Marcos David 2010-08-16 12:47:40 UTC
Output from plasmoidviewer:

plasmoidviewer opendesktop
Pfade:  ("/home/mdavid/.kde4/lib/", "/usr/lib/") 
Trying to load  "/home/mdavid/.kde4/lib//attica_kde.so" 
Trying to load  "/usr/lib//attica_kde.so" 
Using Attica with KDE support 
plasmoidviewer(10846)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(127, 0) 
QGraphicsLinearLayout::removeAt: invalid index 1
plasmoidviewer(10846)/libplasma Plasma::FrameSvg::resizeFrame: Invalid size QSizeF(127, 0) 
Loaded paths from config: (QUrl("http://download.kde.org/ocs/providers.xml") )  
Adding provider "https://api.opendesktop.org/v1/" 
providerAdded  QUrl( "https://api.opendesktop.org/v1/" )  
Getting person list "Near\provider:https://api.opendesktop.org/v1/\latitude:00.00\longitude:0.0000\distance:0" failed with code 1 
Getting person list "ReceivedInvitations\provider:https://api.opendesktop.org/v1/" failed with code 1 
Getting person list "Friends\provider:https://api.opendesktop.org/v1/\id:someone" failed with code 1
Comment 15 Dawit Alemayehu 2011-03-01 23:26:54 UTC

*** This bug has been marked as a duplicate of bug 155707 ***