Opened 9 years ago

Last modified 9 years ago

#11908 new defect

Libpurple does not authenticate to HTTP proxy servers for port 80 requests

Reported by: evands Owned by:
Milestone: Component: libpurple
Version: 2.7.0 Keywords:
Cc: JoernH

Description

Adium #13984 details the problem and has a log. It appears that purple_util_fetch_url_request_len_with_account() from yahoo_login() isn't authenticating to the proxy server but instead just returning an error.

Attachments (3)

pidgin_debug.log (24.1 KB) - added by JoernH 9 years ago.
debug log
pidgin.yahoo.debug.log (21.8 KB) - added by JoernH 9 years ago.
NEW.pidgin.yahoo.log (32.6 KB) - added by JoernH 9 years ago.
Login works !

Download all attachments as: .zip

Change History (21)

comment:1 Changed 9 years ago by evands

Debug log:

08:19:49: -[CBPurpleAccount setAccountUserImage:withData:]: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob setting icon data of length 0
08:19:49: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob: Updating status for key: User Icon
08:19:49: Connecting with proxy type 3 and proxy host localhost
08:19:49: Adium: Connect: XXXXXX_bob initiating connection using status state <AIStatus: 2543a30 [Available]> ((null)).
08:19:49: Setting status on 16a23ef0 (XXXXXX_bob): ID available, isActive 1, attributes {
}
08:19:49: (Libpurple: account) Connecting to account XXXXXX_bob.
08:19:49: (Libpurple: connection) Connecting. gc = 0x199f5f10
08:19:49: Connecting: gc=0x199f5f10 (Connecting) 1 / 2
08:19:49: (Libpurple: util) requesting to fetch a URL
08:19:49: (Libpurple: dns) DNS query for 'localhost' queued
08:19:49: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob: Updating status for key: Online
08:19:49: ************ XXXXXX_bob --step-- 1
08:19:49: -[AdiumPurpleDnsRequest startLookup]: Performing DNS resolve: localhost:1080
08:19:49: DNS resolve complete for localhost:1080; 3 addresses returned
08:19:49: (Libpurple: dnsquery) IP resolved for localhost
08:19:49: (Libpurple: proxy) Attempting connection to ::1
08:19:49: (Libpurple: proxy) Connecting to vcs1.msg.yahoo.com:80 via localhost:1080 using HTTP
08:19:49: (Libpurple: proxy) Connection in progress
08:19:49: (Libpurple: proxy) Connected to vcs1.msg.yahoo.com:80.
08:19:49: (Libpurple: proxy) HTTP proxy connection established
08:19:49: (Libpurple: proxy) Connected to vcs1.msg.yahoo.com:80.
08:19:49: (Libpurple: util) request constructed
08:19:49: Called write with no write_tag <SourceInfo 0x193574e0: Socket 0x179d93c0: fd 25; timer_tag 0; read_tag 680; write_tag 0>
08:19:50: (Libpurple: util) Response headers: 'HTTP/1.0 407 Proxy Authentication Required
Server: squid/2.7.STABLE6
Date: Fri, 14 May 2010 13:22:34 GMT
Content-Type: text/html
Content-Length: 1296
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Basic realm="Squid proxy-caching web server"
X-Cache: MISS from XXXXXX.mine.nu
X-Cache-Lookup: NONE from XXXXXX.mine.nu:3128
Via: 1.0 XXXXXX.mine.nu:3128 (squid/2.7.STABLE6)
Connection: close

'
08:19:50: (Libpurple: util) parsed 1296
08:19:50: (Libpurple: yahoo) No CS address retrieved!  Server response:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>ERROR: Cache Access Denied</title> <style type="text/css"><!--   %l  body :lang(fa) { direction: rtl; font-size: 100%; font-family: Tahoma, Roya, sans-serif; float: right; } :lang(he) { direction: rtl; float: right; }  --></style> </head> <body> <div id="titles"> <h1>ERROR</h1> <h2>Cache Access Denied.</h2> </div> <hr>  <div id="content"> <p>The following error was encountered while trying to retrieve the URL: <a href="http://vcs1.msg.yahoo.com/capacity">http://vcs1.msg.yahoo.com/capacity</a></p>  <blockquote id="error"> <p><b>Cache Access Denied.</b></p> </blockquote>  <p>Sorry, you are not currently allowed to request http://vcs1.msg.yahoo.com/capacity from this cache until you have authenticated yourself.</p>  <p>Please contact the <a href="mailto:webmaster%W">cache administrator</a> if you have difficulties authenticating yourself or <a href="http://XXXXXX.mine.nu/cgi-bin/chpasswd.cgi">change</a> your default password.</p>  <br> </div>  <hr>  <div id="footer"> <p>Generated Fri, 14 May 2010 13:22:34 GMT by XXXXXX.mine.nu (squid/2.7.STABLE6)</p> <!-- ERR_CACHE_ACCESS_DENIED --> </div> </body></html> 
08:19:50: (Libpurple: connection) Connection error on 0x199f5f10 (reason: 0 description: Unable to connect: The server's response did not contain the necessary information)
08:19:50: Connection Disconnected: gc=199f5f10 (Unable to connect: The server's response did not contain the necessary information)
08:19:50: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob accountConnectionReportDisconnect: Unable to connect: The server's response did not contain the necessary information
08:19:50: (Libpurple: account) Disconnecting account XXXXXX_bob (0x16a23ef0)
08:19:50: (Libpurple: connection) Disconnecting connection 0x199f5f10
08:19:50: Disconnected: gc=199f5f10
08:19:50: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob: Telling the core we disconnected
08:19:50: <ESPurpleYahooAccount:2674530 3>:XXXXXX_bob: Disconnected ("Unable to connect: The server's response did not contain the necessary information"): Automatically reconnecting in 87.963882 seconds (8 attempts performed)
08:19:50: (Libpurple: connection) Destroying connection 0x199f5f10
08:19:54: (Libpurple: util) Writing file accounts.xml to directory /Users/XXXXXX/Library/Application Support/Adium 2.0/Users/Default/libpurple
08:19:54: (Libpurple: util) Writing file /Users/XXXXXX/Library/Application Support/Adium 2.0/Users/Default/libpurple/accounts.xmlXXXXXX

comment:2 Changed 9 years ago by evands

The user notes that the same configuration in versions of Adium prior to the new pager-server-lookup-code worked fine with this proxy.

comment:3 Changed 9 years ago by rekkanoryo

I can't see any reason for this to fail to authenticate to the proxy server, as purple_util_fetch_url_request_len_with_account() uses purple_proxy_connect() internally for HTTP URLs (which this one is).

comment:4 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Isn't this #10880 / #10856 / others (see also #2910)?

comment:5 follow-up: Changed 9 years ago by evands

  • Status changed from pending to new

This does look related to #2910 on first blush, anyways... but weren't the changes mentioned there backed out 4 months ago, with #10880 and #10856 therefore fixed?

I've double-checked that im.pidgin.adium.1-4 includes a35d515dd2c8f385ed4563358fccee9108573018, the disapproval of [d6f80b7b] which fixed those tickets.

comment:6 in reply to: ↑ 5 Changed 9 years ago by darkrain42

Replying to evands:

This does look related to #2910 on first blush, anyways... but weren't the changes mentioned there backed out 4 months ago, with #10880 and #10856 therefore fixed?

I've double-checked that im.pidgin.adium.1-4 includes a35d515dd2c8f385ed4563358fccee9108573018, the disapproval of [d6f80b7b] which fixed those tickets.

Yeah, it should be fixed. Oh well. Maybe the user could re-run with PURPLE_UNSAFE_DEBUG set and confirm that the credentials aren't being sent?

comment:7 Changed 9 years ago by JoernH

Hi,

I have this problem, and created a debug.log with 2.7.1. I hope it is OK and that it can help. I edited out my yahoo_user account and replaced with xxxx I also edited out the IP of our proxy server and replaced with xx.xx.xx.xx.

Kind regards

Jørn

Changed 9 years ago by JoernH

debug log

comment:8 follow-up: Changed 9 years ago by rekkanoryo

evands: If possible, please have the user test with the changes I committed in 1724c0c7cbf56b08b5454e796b80173ec9aef481 and (much more importantly) 06fcbcb8d044bcd6887415dc87274071bb724596. I'm hoping the latter revision's fix will kick in first and make the connection succeed.

JoernH: Can you try with this installer? Also, please post another debug log whether it works or not, of course with the same sanitizing you've done to the current log if you feel it necessary.

comment:9 in reply to: ↑ 8 Changed 9 years ago by JoernH

Replying to rekkanoryo:

JoernH: Can you try with this installer? Also, please post another debug log whether it works or not, of course with the same sanitizing you've done to the current log if you feel it necessary.

DONE - Still no connection success :-( attaching log to ticket.

Changed 9 years ago by JoernH

comment:10 Changed 9 years ago by JoernH

I humbly apologize. My Yahoo login DOES work ! ( after the reboot ? ) I will create and attach a new debug log !

Kind regards

Jørn

Changed 9 years ago by JoernH

Login works !

comment:11 Changed 9 years ago by rekkanoryo

JoernH: Excellent! Pidgin 2.7.2 will contain the fixes.

comment:12 Changed 9 years ago by evands

Thanks for the fixes, John :)

comment:13 Changed 9 years ago by rekkanoryo

evands: If you are able to have the user test these fixes, please do not close the ticket if the build works. Daniel has discovered an underlying issue causing this problem that my fixes have just papered over. This ticket should stay open as it covers that problem.

comment:14 Changed 9 years ago by rekkanoryo

  • Component changed from Yahoo!/Yahoo! JAPAN to libpurple
  • Owner sulabh.dev deleted
  • Summary changed from Yahoo no longer connects via an authenticated proxy (error loading pager server) to Libpurple does not authenticate to HTTP proxy servers for port 80 requests

comment:15 Changed 9 years ago by rekkanoryo@…

(In b002aa7c53145ba5350bf1b2ed47059a4018c79a):
ChangeLog all the changes I've made to the Yahoo prpls so far. Refs #11986. Refs #11908.

comment:16 Changed 9 years ago by datallah@…

(In baeaaf7de69d9f99b7545dda73f219292c4dd106):
Attempt to improve handling of HTTP requests on port 80 when there is a HTTP proxy that requires authentication involved. This also has a fix to make sure that we continue to use the same proxy when we are redirected to an alternative URL. I'm tempted to create a purple_proxy_append_proxy_auth_headers(), but that would have to wait until 2.8.0. Refs #11986. Refs #11908.

comment:17 Changed 9 years ago by rekkanoryo

evands: Testing with Daniel's baeaaf7d and capturing a debug log would be better, as this should handle the proxy authentication.

comment:18 Changed 9 years ago by rekkanoryo@…

(In dd496d006f7414efd30774f23f17af433cd38a0e):
* Plucked cfe0e649dda34d9252d40d8f67e445336a247998 (darkrain42@…): yahoo: Fix a few race-condition crashes at login

(if the account disconnects while these fetches are in-progress).

* Plucked 1724c0c7cbf56b08b5454e796b80173ec9aef481 (rekkanoryo@…): Very hackily implement a fallback mechanism in Yahoo, but not for Yahoo Japan because we don't know hosts we can fall back to there yet. This fallback mechanism just blindly connects to scsa.msg.yahoo.com if the HTTP-based CS lookup fails. I guarantee this will break in the future. Refs #11986.

* Plucked 06fcbcb8d044bcd6887415dc87274071bb724596 (rekkanoryo@…): Change the function of the "proxy_ssl" account option to cover regular HTTP requests as well as HTTPS requests. While this does fix the core issue of #11986, there is still more that I need to do to fix his issue. Refs #11986.

* Plucked f08e4f567582f7d28683d043f759a720ee9142e3 (rekkanoryo@…): Make HTTP proxy detection in the yahoo prpls a bit more robust. This should solve some weird proxy related items I couldn't figure out before. Refs #11986.

* Plucked baeaaf7de69d9f99b7545dda73f219292c4dd106 (datallah@…): Attempt to improve handling of HTTP requests on port 80 when there is a HTTP proxy that requires authentication involved. This also has a fix to make sure that we continue to use the same proxy when we are redirected to an alternative URL. I'm tempted to create a purple_proxy_append_proxy_auth_headers(), but that would have to wait until 2.8.0. Refs #11986. Refs #11908.

* Plucked 52fb5cb4cd8795906a7313dd5edde763a4848a3e (qulogic@…): Normalize the remote passport before sending a P2P message. If it's not lowercase, then the switchboard will reject it, causing a whole lot of extra network traffic as Pidgin attempts to resend the same (incorrect) message.

Fixes #11532.

* Plucked e3dd36706068f3b8eabd630ff71d270c145cce42 (markdoliner@…): If we get an error SNAC on the ICBM family and it's missing buddy name then don't fallthrough to the default error handler in misc.c. This was causing purple_parse_msgerr() in oscar.c to get called with different va_args than it was expecting, which caused a crash. Specifically when trying to fetch the ICQ x-status of an offline buddy.

Fixes #11863. This is nosnilmot's patch, I believe. I had no part in it, other than verifying that I do believe it'll fix the crash.

The above revision plucks authorized by Zac West and Robert Vehse.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!