Bug 523922

Summary:	Proxy Authentication Config doesnt work against SQUID running on SLES11
Product:	[openSUSE] openSUSE 11.1	Reporter:	John Moore <JohnFM3>
Component:	YaST2	Assignee:	Katarina Machalkova <kmachalkova>
Status:	RESOLVED DUPLICATE	QA Contact:	Jiri Srain <jsrain>
Severity:	Major
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	i686
OS:	openSUSE 11.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description John Moore 2009-07-21 17:18:52 UTC

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 1.1.4322; MS-RTC LM 8)

As I understand if I use yast2 proxy to configure my Systems proxy settings, then FireFox (which I use primary) and Konqueror when set to use system settings (regarding proxy) should use the settings provided by the yast module to connect to the Internet.

When I dont have Authentication configured on my SQUID Server (SLES11), and I configure the client proxy via yast, I can connect to the Internet and browse around as Expected.

When I configure my SQUID Server to use Basic Authentication, and not add the credentials to the client Proxy settings, I can open FireFox which shows a popup asking for USERNAME & PASSWORD, after which is entered I can browse the internet with out issue.

When I configure the client computer with the yast module to include the Proxy Credientials, and try to test. The test fails with referenct to not providing the USERNAME & PASSWORD. IF you finish, and re-open the module and test again. It will work. Further more, if you open FireFox, it will still ask for USERNAME & PASSWORD. And if you cancel that, the SQUID server denies you access to the Internet. Which is why I assume the yast module isnt correctly applying the credentials to the system.

Also, the /etc/sysconfig/proxy file shows no reference to how to add credentials manualy.

If I want to continue using Authenticated Proxy, I am unable to use Yast's ability to update my box from OpenSuSE's sources as the module has no way to be granted access thru the proxy.

Reproducible: Always

Steps to Reproduce:
1. Configured SQUID Server to require proxy_auth (tested against basic authentication)
2. Added credentials to proxy module on client
3. Tried Testing with the test proxy button ~ Problem shows itself right there.
4. Test with firefox ~ You will recieve a pop up asking for credentials.
Actual Results:
System ignores the Credentials entry's in the yast module.

Expected Results:
FireFox should have connected to the Internet without asking for Credentials.

This was tested against KDE. Due to the fact that I am working with a Yast Module, I wouldnt expect themes to affect.

Comment 1 Katarina Machalkova 2009-08-10 17:14:15 UTC

Need more info.
Please check that correct data gets written into /etc/sysconfig/proxy (as for proxy URL). Auth credentials should be in /root/.curlc. Also please make sure that you relogin your user after changing the proxy settings. This is necessary to apply the changes. 

If anything is wrong in the above files and if even the relogin does not help (for Firefox to pick up the new settings) please attach YaST logs.

Comment 2 Katarina Machalkova 2009-08-11 15:00:14 UTC

Ok, forget the needinfo, this is a copy of bug 227513 and it is not really trivial to fix (if at all)

Summary:
Proxy auth credentials are written into /root/.curlrc file, and as they're not exported into environment, only curl-based apps (such as YaST) can see them. 

There is not much applications that can read proxy URL with user/password from $http_proxy variable. Firefox can, but only after installing an add-on (https://addons.mozilla.org/cs/firefox/addon/3896), few other examples are in bug 227513, comment #21. Thus there is no use in trying to have auth credentials exported as env. variables, if hardly any app can use them in this form.

Marking as duplicate, but it is rather 'wontfix' ('cantfix' is maybe more appropriate)

Comment 3 Katarina Machalkova 2009-08-13 08:54:00 UTC

Really a duplicate

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