Jira/Confluence werkend krijgen met nginx-reversproxy ervoor

[Boudewijn]

Hoi allemaal,


Ik heb een debian-machine bij amazon waar ik Jira en Confluence op wil draaien. Beide zijn een Tomcat container op een eigen poort, die wordt door een nginx server gereverse-proxied.
Alle software staat op een en dezelfde machine.

Nginx praat HTTPS met de client, en HTTP met Jira/Confluence. Dat maakt beheer veel makkelijker , en anders werkt die reverse proxy volgens mij ook niet handig.
De client kan naar atlassian.bla.com/jira of /confluence gaan.


Alles lijkt te werken, maar ik krijg XSRF errors als ik een project aan wil maken. Frustrerend, want het werkt dus wel een beetje
Ik heb diverse browsers geprobeerd, met en zonder addblockers .
Goed, ik heb de manual gelezen:
https://confluence.atlass...-using-ssl-802593043.html
https://confluence.atlass...with-nginx-426115340.html


Desalniettemin heb ik ergens teveel gepield en weet ik niet waar de fout zit .
Mijn nginx config:

code:

server {
    server_name atlassian.x.nl;
    listen 80;
    location / {
        return 301 https://$server_name$request_uri;
    }
}


server {
    listen 443 ssl;
    server_name atlassian.bla.nl;
    ssl_certificate /etc/ssl/bla
    ssl_certificate_key /etc/ssl/private/bla;


    location /jira {
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://localhost:8080/jira;
        client_max_body_size 10M;
    }
}

In de server.xml van jira vind je:

code:

        <!--
         ==============================================================================================================
         HTTP - Proxying Jira via Apache or Nginx over HTTP

         If you're proxying traffic to Jira over HTTP, uncomment the below connector and comment out the others.
         Ensure the proxyName and proxyPort are updated with the appropriate information if necessary as per the docs.

         See the following for more information:

            Apache - https://confluence.atlassian.com/x/4xQLM
            nginx  - https://confluence.atlassian.com/x/DAFmGQ
         ==============================================================================================================
        -->


        <Connector port="8080" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
                   maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
                   acceptCount="100" disableUploadTimeout="true" bindOnInit="false" scheme="http"
                   proxyName="atlassian.x.nl" proxyPort="80"/>

Deze code heb ik aangezet en de andere Connectors uitgezet.

Goed na een berg gepiel met context's in configs en in de admin interface kom ik er achter dat ik mijn proxyPort op 443 moet zetten. dan werkt het wel, dat heeft niets te maken met de port waarop tomcat draait maar naar de port waarop de site geserveerd wordt.

Lekker dat ik mijn topicstart vernaggel en tijdens dit te typen erachter kom. Goed bezig .

[ Voor 171% gewijzigd door Boudewijn op 31-07-2018 21:04 ]

[HollowGamer]

CSRF is een protectie die ervoor moet zorgen dat er geen aanvallen/hacks kunnen plaatsvinden vanuit een ander adres, dus je moet inderdaad hierin aangeven dat je over HTTPS praat i.p.v. HTTP.

Ik snap je verhaal niet helemaal. Applicaties achter je proxy moeten weten dat het over SSL/TLS gaat, anders gaan zij verkeer sturen over HTTP. Het scheelt tevens niet zo heel veel CPU hoor, dus gewoon SSL gebruiken. Verder als het kan linken over socket, zo doe ik dat met o.a. Gitlab.

[Boudewijn]

Ja ik weet wat CSRF is, het is ondertussen ook opgelost (zie onderste regel ) .


Punt is dat JIRA een HTTP URL verwacht en HTTPS krijgt. Vandaar de CSRF. Mijn SSL termineer ik netjes op nginx, niet op de Jira/Confluence instances... omdat er meerdere dingen achter de reverse proxy komen te hangen en ik het liever op 1 plek regel. Vandaar.

Dank voor je input .

[Hero of Time]

Puur voor reverse proxy zaken pak ik veel liever haproxy. Vind ik zelf makkelijker en kan ontzettend veel. Sommige webapplicaties laten zich niet al te makkelijk proxy'en, maar met haproxy gaat dat dan weer wel. En als je liever per site een bestand hebt (standaard haproxy is alles in 1 bestand), dan maak je een map aan met de naam van het config bestand wat normaal gebruikt wordt (/etc/haproxy/haproxy.cfg) en zet je daarin je config in losse bestanden. Alfabetische volgorde aanhouden en klaar (je kan dus 00default.cfg, 01site1.cfg, etc gebruiken). Werkt iig met 1.8, niet met 1.5, geen idee voor tussenliggende versies.

[HollowGamer]

Dat je SSL op elke instance moet instellen zeg ik niet, enkel dat je daar moet aangeven dat het over HTTPS gaat.

Je hangt inderdaad het certificaat aan je hoofd, en de rest van je instances hoeft dit als het goed is niet te beheren. Het zou dan fijn zijn als dit een wildcard is, maar je kan zoveel instellen en het zo gek maken als je zelf wilt.

Ik ben helaas niet bekend met Jira zelf hosten, maar praat deze niet met node? Is luisteren over een socket mogelijk?

[ Voor 13% gewijzigd door HollowGamer op 31-07-2018 21:37 ]

[Hero of Time]

Jira en Confluence draaien in een (meegeleverde) Tomcat instance. Die doet niet aan sockets vziw. En als het zakelijk is (wat vaak het geval is met deze producten), zet je je reverse proxy in een DMZ en de applicatieservers in een intern netwerk. Sockets zijn dan niet echt een optie meer.

[HollowGamer]

@Hero of Time Je bedoelt hier ook mee mochten apolicaties op verschillende servers/in VMs draaien?

Stomme vraag, maar wil je een DMZ niet voorkomen? Want dan mapt die bijna alles, incl. apps/services die je niet wilt? Tenzij je op alles een whitelist kan instellen van de proxy, toch?

[ Voor 13% gewijzigd door HollowGamer op 31-07-2018 21:47 ]

[Hero of Time]

Ja, je scheidt meestal je applicaties van je reverse proxy, anders heeft het niet heel veel zin om een reverse proxy in te richten. Dan kan je namelijk net zo goed je applicatie op 443 laten luisteren en met SSL configureren.

En waarom zou je een DMZ willen voorkomen? Heb je al eens onderzocht wat er met een DMZ netwerk wordt bedoelt? Er zit in principe altijd nog een firewall tussen. Op m'n vorige werk was er een apart vlan voor DMZ met een firewall er voor. Elk inkomende en uitgaande poort gaven we door en werd toegestaan in de firewall. Machine 1 kan alleen met machine 2 communiceren en machine 3 met machine 4 en 5 bijvoorbeeld.

[sanzut]

Jira over SSL is een klotewerk om in te richten in Jira zed. En het moet bij elke update opnieuw.
Wij gebruiken ook een reverse prozy, maar dan in Apache. Ik heb e.e.a. nu niet bij de hand, maar volgens mij moet je in de connector en in de applicatie zelf de werkelijke HTTPS poort en URL instellen, die de clients gaan gebruiken. Anders krijg je inderdaad gekke fouten

[sanzut]

Toch even gekeken.

VHost, Poort 80: ACME chalenge voor Lets Encrypt, verder forward naar HTTPS

code:

<VirtualHost *:80>
    ServerAdmin [e-mail]
    ServerName jira.domeinnaam.nl
    ServerAlias jira
    DocumentRoot C:\Bitnami\wampstack-5.6.30-2\apache2\htdocs\

    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge [NC]
    RewriteRule ^(.*) https://jira.domeinnaam.nl/$1 [R=301,L]

    ErrorLog C:\Bitnami\wampstack-5.6.30-2\apache2\logs\jira-http-error.log
    LogLevel warn
    CustomLog C:\Bitnami\wampstack-5.6.30-2\apache2\logs\jira-http-access.log combined
</VirtualHost>

VHost, Poort 443; Proxy

code:

<VirtualHost *:443>
    ServerAdmin [e-mail]
    ServerName jira.domeinnaam.nl
    DocumentRoot C:\Bitnami\wampstack-5.6.30-2\apache2\htdocs\
    ErrorLog C:\Bitnami\wampstack-5.6.30-2\apache2\logs\jira-https-error.log
    LogLevel warn
    CustomLog C:\Bitnami\wampstack-5.6.30-2\apache2\logs\jira-https-access.log combined

    Header set Access-Control-Allow-Origin "http://zegikniet.domeinnaam.nl" 
    Header set Access-Control-Allow-Origin "https://zegikniet.domeinnaam.nl"    

    SSLEngine On    
    SSLCertificateFile "C:/LetsEncrypt/Storage/certs/acme-v01.api.letsencrypt.org.directory/jira.domeinnaam.nl/cert.pem"
    SSLCertificateKeyFile "C:/LetsEncrypt/Storage/certs/acme-v01.api.letsencrypt.org.directory/jira.domeinnaam.nl/key.pem"
    SSLCertificateChainFile "C:/LetsEncrypt/Storage/certs/acme-v01.api.letsencrypt.org.directory/domeinnaam.nl/fullchain.pem"

    SSLProxyEngine          On
    ProxyRequests           Off
    ProxyPreserveHost       On
    ProxyPass               "/.well-known/acme-challenge/" "!"
    ProxyPass               /       http://localhost:8081/
    ProxyPassReverse        /       http://localhost:8081/
</VirtualHost>

jira/conf/server.xml

code:

    <Service name="Catalina">

        <!-- Apache Proxy Connector with values for scheme, proxyName and proxyPort -->
        <Connector port="8081"
                   maxThreads="150"
                   minSpareThreads="25"  
                   connectionTimeout="20000" 

                   enableLookups="false"
                   maxHttpHeaderSize="8192"
                   protocol="HTTP/1.1"
                   useBodyEncodingForURI="true" 
                   redirectPort="8443"
                   acceptCount="100"
                   disableUploadTimeout="true"

                   scheme="https"
                   proxyName="jira.domeinnaam.nl"
                   proxyPort="443"/> 
    
        <Connector port="8080"

                   maxThreads="150"
                   minSpareThreads="25"
                   connectionTimeout="20000"

                   enableLookups="false"
                   maxHttpHeaderSize="8192"
                   protocol="HTTP/1.1"
                   useBodyEncodingForURI="true"
                   redirectPort="8443"
                   acceptCount="100"
                   disableUploadTimeout="true"/>

[Hero of Time]

@sanzut, het is al opgelost door TS, zie de laatste regel daarvan. En je hoeft voor extra toevoeging niet te dubbelposten. Het had prima in dezelfde post gekund.