Support of webproxy (http,https)

[Winfried]

For different reasons I am implementing some external security devices into my private network (.i.e. firewall, url-filter, virus-scan and a squid-based (explicit) proxy)
For some functions IMatch5 needs access to the internet: access to some geo/gps-data, update checking, etc.
I would like to be able to define a http/https-proxy for this kind of access to the internet.

Winfried

[Mario]

IMatch uses an embedded Internet Explorer, and this automatically uses the settings you make for Internet Explorer, including proxy settings and the like.

[Winfried]

I normally use firefox. So I did not set the proxy settings for Internet Explorer.
After done so, it works fine for the "Geonames App" and for the reverse geocoding tool,
but it does not work for the map panel and for the check for updates function.
Installed Internet Explorer Version 11

Winfried

[Mario]

I don't think my check for updates function supports proxies or tunneling. I kept it simple. It is supposed to use the IE settings as well.

When you say "Does not work for the Map panel", what does this mean?
IMatch loads a local HTML page from the disk to host the map, and then uses OpenLayers to load map data from the Internet. The requests to the map server are done by the embedded IE control uses by Windows. I have no influence or control how this control connects to the Internet, it uses the settings made for IE.

When you run IMatch 5 with debug logging, does it write any error messages to the log file? Does it show error messages in the Map panel?

[Winfried]

I did some more tests.
The message says that there is no connection to the internet.

In a next step I opnened the firewall.
No surprise all worked fine.

Then I switched on a network-trace (tcpdump).
Good news: The access for the open map uses the proxy.

Bad news: There is also a request to google(maps?) (IP 173.194.69.99), that does not use the proxy.
This connection is not used, just build up (syn;syn,ack;ack and fin,ack; fin,ack;ack)

If I block the access to the google-IPs, I don't see any request towards the open map IPs.

So I assume that in the code there is still some reference to the former google map implementation.

Winfried





[attachment deleted by admin]

[Mario]

Maybe the OpenLayers framework used by IMatch pings Google to check for API updates or something. I don't know.
IMatch never calls Google or any of the other map services directly, only via OpenLayers.

What with the Check for Update call? It also should use the proxy settings of IE.

[Winfried]

What with the Check for Update call? It also should use the proxy settings of IE.

No the Update call goes direct. It is a https request to 87.106.9.227

It is a 1&1-Server

Winfried

[Mario]

As far as I can see the library first tries a direct request, and if this fails uses the proxy settings for the current user from IE, and if this also fails using per-URl proxy settings. What type of proxy are you using and how is it configured?

[Winfried]

It is a squid 3.1.16.5  on a QNAP NAS box.

No special settings. Just out of the box.
I will try to find out some more data.

Winfried

[Winfried]

Last night I did some more tests.
There are 4 test-cases:
1 version-check
2 map-panel
3 geonames app
4 reverse geocoding tool

To sum it up:
case 3 & 4 work fine with the proxy
case 1 & 2 don't work

To pin down the problem I installed wireshark on my PC and traced the ethernet Interface.
For case 1 & 2 I didn't see any request to the proxy, even after the direct request fails. I tested even with different "kinds" of failure (blocked, rejected).
I also cleared the IE-cache.

The request in case 1 (version-check) is a https-request.

For case 2 I saw a request to some google-IP-addresses. (ajax.googleapis.com, maps.google.com)
If I block these requests at the firewall, the map panel shows an error messages.
If I don't block these requests to google, all other request to the geonames-server go smothly over the proxy.
I found the following lines of code in the file "imatchgeo_ol.htm"

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   
   <script src="http://maps.google.com/maps/api/js?v=3&sensor=false"></script>

ok, I am not a developer and I am unable to code anything, but maybe these lines together with the settings of some variables in the *.pts-file oder the database may be a reason for this behaviour.

Winfried

[Mario]

These scripts are required. If you block IMatch from loading these scripts, the Map panel cannot work. jQuery is a standard library and there is always the check if the cached version is current. This is all controlled by the script code in the start HTML page IMatch loads from the local disk, and from the initialization code of OpenLayers. Don't block it if you want the Map panel to work.

The update check and the generic WebRequest scripting function implemented in IMatch use standard HTTP(S) with procxy support as specified in the system-wide or user-specific proxy settings. If they don't work on your machine, I have no idea. I tested it with a full Enterprise proxy and they handle it correctly. I don't have Squid or a Linux box at this time and hence I cannot do any more testing.

[Winfried]

Mario, thanks for the explications.
So I guess there is a problem with the proxy settings on OS-level on my box and I will open the firewall for these IPs/URLs.
Since I am responsible for a farm of about 40 Bluecoats, I am aware of the differences between squid and an Enterprise proxy.
But here it is not a proxy problem, but a Windows problem. We observe sometimes similar problems with the proxy settings of some clients in my company.

Problem not solved, but there is nothing you can do to solve it.
Thanks again
Winfried