search

devonfw / devon4j

devonfw Java stack - create enterprise-grade business apps in Java safe and fast
Apache License 2.0
82 stars 88 forks source link

devon4j-starter-http-client-rest-sync creating tripple slash in URL #461

Closed hohwille closed 2 years ago

hohwille commented 2 years ago

Expected behavior

As a devon4j user, I want to be able to use ServiceClientFactory seamlessly so that I can invoke REST services easily.

Actual behavior

When I use devon4j-starter-http-client-rest-sync my backend rejects the request with the error message:

The request was rejected because the URL contained a potentially malicious String "//"

The reason is that the URL constructed automatically by devon4j-http-client-rest-sync contains localhost:«port»///services/rest/.... The part after host and port with the tripple slashes does not seem to come from my user-code of the REST client invocation nor from my configuration in application.properties. It seems to be a bug inside the devon4j code constructing the URL.

Steps to reproduce (bug) / Use Case of feature request (enhancement)

  1. Create a new devon4j app (devon java create com.example.demo)
  2. Create a simple hello world rest service
  3. Uncomment dependency devon4j-starter-http-client-rest-sync from core/pom.xml
  4. Create a JUnit test invoking this REST service using ServiceClientFactory that is extending RestServiceTest.
  5. Run the test and check the logs

Related/Dependent Issues

Comments/Hints:

Affected version:

hohwille commented 2 years ago

Analysis:

  1. this is a general bug here: https://github.com/devonfw/devon4j/blob/master/modules/service/src/main/java/com/devonfw/module/service/common/impl/discovery/ServiceDiscovererImplConfig.java#L91 The contextPath may be "/". In that case "/" is appended as contextPath followed by another static /. The /services is appended ending in the tripple slashes.
  2. CXF client seems to normalize the URL so the server does not receive the tripple slashes. Unlike the http client we implemented uses the URL as is leading to the bug.

First of all we should fix the kind of bug in ServiceDiscovererImplConfig creating this strange URL. Next we should consider an improvement to also normalize the URL in general in our service client to prevent such problems even in case of missconfiguration (e.g. @Path annotations ending with / on class level and starting with / on method level or also similar errors in application.properties). In the end we want to have a good user-experience and help developers invoking services flawlessly.