tycho icon indicating copy to clipboard operation
tycho copied to clipboard

Update testcase to emulate corporate proxy

Open Torbjorn-Svensson opened this issue 2 years ago • 6 comments

The testcase wrongly assumed that the client can resolve the domain name. Some corporate networks with proxy have internal name servers that does not include public records and this, resolving any non-internal domain names will fail. The proxy servers are having one leg in the real world and can thus resolve public records.

I've only updated the test case as I'm unable to build of tycho for some unknown reason.

To validate that the testcase did the intended, I had to:

  1. Remove every module in /pom.xml except tycho-its and tycho-testing-harness.
  2. Remove every java file in /tycho-its/src/test/java/ except /tycho-its/src/test/java/org/eclipse/tycho/test/TYCHO279HttpProxy/ProxySupportTest.java.
  3. Build using mvn -Dtycho-build-version=4.0.3 clean package.

Hope this fulfills the request for help in https://github.com/eclipse-tycho/tycho/issues/2709#issuecomment-1722854049.

Torbjorn-Svensson avatar Oct 06 '23 20:10 Torbjorn-Svensson

To build/test you usually do:

mvn clean install -DskipTests -T1C

then cd into tycho-its then call

mvn clean install -Pits -Dtest=<classname of your test to run>

laeubi avatar Oct 07 '23 09:10 laeubi

The testcase wrongly assumed that the client can resolve the domain name.

Why is this wrong? I'm not sure if such thing can ever work in a unit test reliable as name service is different from proxy service.

So if you like to have that we either also need to mock a DNS server or one needs to configure a mirror or similar.

laeubi avatar Oct 07 '23 09:10 laeubi

The testcase wrongly assumed that the client can resolve the domain name.

Why is this wrong? I'm not sure if such thing can ever work in a unit test reliable as name service is different from proxy service.

So if you like to have that we either also need to mock a DNS server or one needs to configure a mirror or similar.

Well, if you want the real deal, then no, it would not work, but I'm using a different approach. In the test, I instead of stating the web-server that has the content and let the proxy just tag along, I define a different URL that the proxy knows that it should replace the the real URL. This way, I'm forcing the request to go though the proxy in order to actually resolve to anything, meaning that I emulate that the client cannot do the resolving while the proxy server "can" (obviously it can't but it instead replaces the request). Does this make sense?

client
  -> request http://fake-non-existing-domain/random/path/ from proxy

proxy 
  -> get the request
  -> rewrite URL to http://localhost:12345/test/
  -> send the request of http://localhost:12345/test/
  -> forward the reply back to "client" as data from http://fake-non-existing-domain/random/path/

Obviously, fake-non-existing-domain can be anything that the client cannot access without the proxy. In my case, I assume that there is nothing that matches this string.

Do you think this way to emulate the scenario with a corporate network that requires to go thought a proxy to get out is valid?

Now that I'm thinking about this a 2nd time, I might have missed to replace all links to http://localhost:... with the http://fake-non... part in the reply.

Torbjorn-Svensson avatar Oct 08 '23 08:10 Torbjorn-Svensson

Alright, but now the test fails with a message that proxy was not used while I would expect that it should fail with http://fake-non-existing-domain/random/path/ not found instead ...

laeubi avatar Oct 08 '23 09:10 laeubi

@Torbjorn-Svensson there was a fix in the proxy support recently do you want to rebase your change and see if it fixes your issue?

laeubi avatar Jan 06 '24 07:01 laeubi

@Torbjorn-Svensson can you rebase and resolve conflicts?

laeubi avatar Jan 23 '24 05:01 laeubi