[Artifactory-developers] [JFrog JIRA] Created: (RTFACT-1026) Artifactory should work behind a frontend web server

[Tuomas J. (JIRA) <ji...@jf...>]

Artifactory should work behind a frontend web server
----------------------------------------------------

                 Key: RTFACT-1026
                 URL: http://www.jfrog.org/jira/browse/RTFACT-1026
             Project: Artifactory
          Issue Type: New Feature
          Components: Web UI
    Affects Versions: 1.3.0-beta-6
            Reporter: Tuomas Jormola
            Assignee: Yoav Landman


Hi,

At our company, we have following kind of setup:

Client <-> F5 BIG-IP LTM frontend device with public IP address for the Archiva server <-> Web server backend with private network

The Archiva service is accessed using HTTPS so that the frontend device first gets the request from clients, processes the SSL protected traffic, and passes the request to the backend server running Archiva (potentially, there could be several backends to choose from for high availability and load balancing, but for Archiva, we're just using a single server) using HTTP. The response from Archiva comes back to the frontend device, is wrapped to the existing SSL session and returned to client.

This works great unless the application is relying on the parameters of the server it's being run on, e.g. the port of the server, protocol scheme and so on. Archiva uses this information to constructs the links to repositories. If run like described above, for example the links to repositories at e.g. http://example.com/archiva/webapp/simplebrowserroot.html are currently broken.

The code that handles this seems to be webapp/src/main/java/org/artifactory/webapp/servlet/RequestUtils.java, method getServletContextUrl(). It uses the HttpServletRequest object provided by the servlet container to build the URL prefix. On our setup, when using Tomcat, the server is smart enough to return correct values for getServerName() (probably due to the Host HTTP Header of the request passed by the client, the value of this header points to the frontend host name the client tried to access, not the hostname of the backend server processing the request), but ports and protocol scheme are wrong, because there's no way Tomcat could know the initial request from the client was done using HTTPS.

My proposal is that Archiva should implement configuration option where one could specify the real URL prefix of the service and if specified, this would be used instead of the URL constructed from HttpServletRequest object. By default, this option would not be set, of course, and the current logic would take place when constructing the servlet context URL.

So e.g. in the artifactory.config.xml one might have

<frontendUrl>https://example.com/maven</frontendUrl>

which would result in repository URLs like

https://example.com/maven/example-repo/

even if the Archiva application is available as http://backend.example.com:10080/archiva/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://www.jfrog.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira