Opened 12 years ago

Closed 11 years ago

Last modified 10 years ago

#2013 closed Bug (invalid)

unable to connect to tracker via authenticated HTTP proxy server

Reported by: sikachu Owned by: charles
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.52
Severity: Normal Keywords: backport-1.8x needinfo
Cc:

Description

I want to connect to the tracker via my own HTTP proxy server, which requires the authentication. So, I set the Proxy server in the Preferences pane to:

Server: --- my server -- Port: 9876 Protocol: HTTP [Check] Authentication is required Username: --- my username --- Password: --- my password ---

After that, I got the '407 (Proxy Authentication Required)' response from it. I've check the username/password for typo, and tried it on the browser, which turns out that username/password I put in those boxes are correct.

I've tried on the latest nighty, r8300, on Mac OS X 10.5 Leopard.

Attachments (1)

Picture 7.png (112.8 KB) - added by sikachu 12 years ago.
Screenshot of the log panel

Download all attachments as: .zip

Change History (20)

Changed 12 years ago by sikachu

Screenshot of the log panel

comment:1 follow-up: Changed 12 years ago by livings124

Does it work on 1.52 (release)?

comment:2 in reply to: ↑ 1 Changed 12 years ago by sikachu

Replying to livings124:

Does it work on 1.52 (release)?

No, that's why I switched and tried on the nighty :)

comment:3 Changed 12 years ago by livings124

  • Version changed from 1.52+ to 1.52

comment:4 Changed 12 years ago by livings124

  • Component changed from Transmission to libtransmission
  • Owner set to charles

comment:5 Changed 12 years ago by charles

Is this still broken in the nightlies?

comment:6 Changed 12 years ago by sikachu

Yes, still broken in r8397

comment:7 Changed 12 years ago by charles

  • Summary changed from Transmission unable to connect to tracker via HTTP proxy server that requires authentication to unable to connect to tracker via HTTP proxy server that requires authentication

comment:8 Changed 12 years ago by charles

Ticket #2237 has been closed as a duplicate of this ticket.

comment:9 Changed 12 years ago by charles

  • Summary changed from unable to connect to tracker via HTTP proxy server that requires authentication to unable to connect to tracker via authenticated HTTP proxy server

comment:10 Changed 12 years ago by garrych

  • Cc garrych@… added

comment:11 Changed 11 years ago by charles

  • Component changed from libtransmission to Transmission
  • Milestone changed from None Set to 1.90
  • Status changed from new to assigned

I think the cause for this on OS X is in Controller.m. The OS X client doesn't appear to be initializing the TR_PREFS_KEY_PROXY_PASSWORD setting on startup; it should be around line 316 with the other proxy settings.

There is a similar bug to this in the GTK+ client, which is fixed now in trunk for 1.90 by r10127.

comment:12 Changed 11 years ago by charles

  • Keywords backport-1.8x added

Adding backport-1.8x tag in the unlikely case that we have another 1.8x release.

comment:13 Changed 11 years ago by charles

edit: looks like maybe PrefsController?.m handles this key separately. Still I've confirmed it's working on the GTK+ client (as of r10127, anyway) so possibly PrefsController? isn't decoding the stored password correctly into plaintext for tr_sessionSetProxyPassword()?

comment:14 Changed 11 years ago by livings124

I have confirmed that the password appears to be set correctly on launch in the Mac UI.

comment:15 Changed 11 years ago by charles

  • Keywords needinfo added

Please answer these questions:

  • Is this reproducible?
  • If so, what specific steps should we take to recreate this bug?
  • Is there a password-protected HTTP proxy that we can use for testing this?

This will help us to find and resolve the problem.

(Note: the backport-1.8x tag is for the GTK+ change, which is a clear simple one-liner bugfix)

comment:16 Changed 11 years ago by charles

  • Milestone changed from 1.90 to None Set

comment:17 Changed 11 years ago by charles

  • Resolution set to invalid
  • Status changed from assigned to closed

I'm closing this bug report because it lacks the information needed to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. Thanks again!

comment:18 Changed 11 years ago by User294

Maybe it is NTLM proxy? They're using quite weird handshake sequence:
On NTLM proxy first you get 407 code regardless of anything for your request.
Then you should retry with another request and must supply valid NTLM stuff.
If client fails to do so, it gets yet another 407 from proxy for its requests so non-NTLM-aware clients would fail at this point.

Such weird sequence (which is not fits well to HTTP nature) used because NTLM auth is a challenge-response so first 407 contains challenge data and client supposed to provide a proper response in retried request. So it could look like if it was proxy with NTLM auth. And yes, most of modern browsers know how to handle NTLM (at least, IE, Firefox and Opera know about this).

comment:19 Changed 10 years ago by garrych

  • Cc garrych@… removed
Note: See TracTickets for help on using tickets.