intrepid: network proxy ignore host list ignored for wildcard

Bug #284250 reported by Biji
34
This bug affects 4 people
Affects Status Importance Assigned to Milestone
gnome-settings-daemon (Ubuntu)
Expired
Low
Unassigned

Bug Description

i've tried adding wildcard to proxy setting, for example:
127.0.0.0/8
192.168.1.0/24
192.168.1.*
nothing ignored... tried using firefox and pidgin..

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?

 This will help us to find and resolve the problem.

Revision history for this message
Biji (biji) wrote :

Yes, it is reproducible..
this is the step:
1. Open System -> Network Proxy
2. Set Manual Proxy Config and set your http,ftp,https proxy
3. Now go to Tab Ignored Host, you will see localhost and 127.0.0.0/8 (as default)
4. Open Firefox and enter on URL: http://127.0.0.1/
this will open proxy's webserver which requested using proxy ..... this is wrong because 127.0.0.1 is included in 127.0.0.0/8
5. now open url localhost ..... this will open your webserver or connection refused if there is none
hope this help

Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is not a gnome-control-center one but firefox not using the GNOME settings

Changed in gnome-control-center:
assignee: desktop-bugs → nobody
status: Incomplete → New
Revision history for this message
Biji (biji) wrote :

I don't maybe this is bigger issue... when I try pidgin also happen.. i tried to add exception to yahoo servers with wildcard... and pidgin still tries to connect using proxy.. when i add full ip address it don't use proxy

Revision history for this message
John Vivirito (gnomefreak) wrote :

Changed package to network-manager since it happens not just to firefox. I will let n-m triagers decide if correct package.

Revision history for this message
Feanor (angelo-pantano) wrote :

i can confirm this bug is still present in intrepid: any wildcard is not being taken into account in proxy settings

Revision history for this message
Naseer Ahmed (naseer) wrote :

I can also confirm this bug with intrepid - it happens to all applications and not just FF

Revision history for this message
Max Waterman (davidmaxwaterman) wrote :

This can be annoying for users behind company firewalls, where the company has hosts both inside and outside the firewall that are in the same domain - eg they're all *.company.com. The only way to distinguish between intranet and internet hosts is using the subnet - unless you list every single combination on the subnet (or just try to maintain a list of IP addresses for each host that fails).

I would dispute the 'low' importance. This is actually 'quite' important...bordering on 'very'.

Revision history for this message
Scott Brown (scotty-b-brown) wrote :

We have finally convinced the powers that be to let developers use ubuntu at work - this is a big problem for us as we have a lot of internal servers, and it would be great to add *.internaldomain.com to the list instead of each individual server each time...

Revision history for this message
marcw (marcw) wrote :

This bug STILL exists in Jaunty. Neither wildcard nor CIDR designation works in this list.

For enterprise environments this is simply unacceptable.

Revision history for this message
Scott Brown (scotty-b-brown) wrote :

This works perfectly for me now at work since upgrading to jaunty.

I put in *.int.company.com and everything on that domain is not proxied.

Revision history for this message
Imre Péntek (pentek-imre) wrote :

I have the same bug on my jaunty, 127.0.0.1 does gets proxyied, however there is the default rule 127.0.0.0/8 on my ignore list. However when I manually add 127.0.0.1 to that list, firefox uses direct connection.

Revision history for this message
Ľubomír Mlích (hater-zlin) wrote :

Ignoring *.mydomain works fine, bude ignoring 192.* or 192.*.*.* or 192.0.0.0/8 do not work in Lucid Lynx 10.4.
Proxy authentication do not work as described in bug #300271

Revision history for this message
Oliver Dungey (oliver-dungey) wrote :

This bug is not a duplicate of bug #556293! As was stated above this is to do with firefox's manner of using the gnome proxy settings. From what I have seen Google Chrome and Firefox interpret the rules very differently - one likes wildcards and the other likes the mask syntax.

We have been struggling for years with Ubuntu and proxy server support and it is a huge issue prohibiting general use in the enterprise. I think we need some new thinking:

If Ubuntu arrived out of the box with a squid proxy server setup in transparent mode with a virtual nic then no applications would need to know about proxy servers - that is how we fix it.

Revision history for this message
Id2ndR (id2ndr) wrote :

This seems to be fixed in natty.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Reported as fixed in Natty. I'd be very tempted to mark this as Fix Released if others can chime in.

Regardless, proxy is not something done by NetworkManager -- it's either available at the system level with the HTTP_PROXY/HTTPS_PROXY variables or via gnome-settings-daemon; so reassigning to that package.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
affects: network-manager (Ubuntu) → gnome-settings-daemon (Ubuntu)
Changed in gnome-settings-daemon (Ubuntu):
status: New → Incomplete
Revision history for this message
Ľubomír Mlích (hater-zlin) wrote :

In 11.10 this configuration is not availaible. Manual config show only server and port.
No exceptions, no user or password.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for gnome-settings-daemon (Ubuntu) because there has been no activity for 60 days.]

Changed in gnome-settings-daemon (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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