Hi Martin,

do you use the current version? Archiva 2.2.3?
There is a CSRF-prevention filter active. You have to add the URL of your 
nginx server to the rest.baseUrl field (you may set a comma separated list for 
multiple URLs).

See http://archiva.apache.org/docs/2.2.3/release-notes.html
Note: If your archiva installation is behind a reverse proxy or load balancer, 
it may be possible that the Archiva Web UI does not load after the upgrade. If 
this is the case you may access the WebUI via localhost or edit archiva.xml 
manually. In the "Redback Runtime Configuration" properties you have to enter 
the base URLs of your archiva installation to the rest.baseUrl field.

See  also:
http://archiva.apache.org/redback/integration/rest.html
http://archiva.apache.org/redback/
configuration.html#Cross_Site_Request_Forgery_CSRF_Prevention

If that does not work please create a JIRA ticket and provide detailed logging 
output.

Greetings

Martin

Am Samstag, 12. August 2017, 10:55:23 CEST schrieb Martin Pola:
> Hello,
> 
> I am trying to access Archiva through HTTPS, and from what I have
> understood the easiest way to accomplish that is by having another,
> HTTPS-enabled, web server acting as a proxy.
> 
> My Archiva instance listens on 127.0.0.1:8080 and my Nginx server block
> looks like this:
>    server
>    {
>        listen [...]:443 ssl;
>        server_name [...]
>        underscores_in_headers on;
> 
>        ssl on;
>        ssl_certificate /etc/letsencrypt/live/[...]/fullchain.pem;
>        ssl_certificate_key /etc/letsencrypt/live/[...]/privkey.pem;
> 
>        location /
>        {
>            include proxy_params;
>            proxy_pass http://127.0.0.1:8080;
>        }
>    }
> 
> The included file `proxy_params` contains these lines:
>    proxy_set_header Host $http_host;
>    proxy_set_header X-Real-IP $remote_addr;
>    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>    proxy_set_header X-Forwarded-Proto $scheme;
> 
> When I try to visit the proxy, Archiva doesn't load. Having opened the
> web browser's developer toolkit, the error appears to have been caused
> by a GET request to
>    /restServices/archivaServices/commonServices/getAllI18nResources
> which the server responded to with error 403 Forbidden. If I try to
> visit Archiva directly, through http://127.0.0.1:8080, the equivalent
> GET request does not return any error. From what I can tell, the same
> request headers seem to be sent, and the same response headers are
> received.
> 
> What could be causing the issue, and how should I proceed to resolve it?
> 
> Kind regards,
> Martin Pola


Reply via email to