TAIGA_SSL_BY_REVERSE_PROXY: "True"

[quen...@electropositive.co.nz]

Hi all, so I have set up a running taiga official docker and used the above, given I'm running behind an existing nginx, which works - mostly.

Has anyone else done this?  I think the most obvious thing is yet again I have a functioning taiga without a functioning events system, which seems to be the bane of my life with this product lol.

The attached shows how I've set it up - though I think it would be better to avoid the 'taiga-gateway' if it were possible to do so.

My question is, has anyone gotten Taiga to work properly behind an existing reverse proxy including the events part?

There are only two scenarios I can think of that could resolve this:

1 - Perhaps the headers aren't being passed from the first nginx to the second nginx properly and some kind of extra config in the first nginx could fix it

2 - I could configure the docker-compose.yml to put the dockers on the default lan network, rather than a container network, which should mean I can bypass the taiga-gateway altogether and run it all straight on my existing nginx reverse proxy.

The other option might be to set up some kind of bridging vlan between the hosts again so that I can remove the taiga-gateway.

Any thoughts?  How would you do it?

Thanks.

[David Barragán]

Hi Marshalleq,

Your scenario is very common for us and it is the one we usually work on. Taiga running behind an nginx that can be used, for example, to configure ssl certificates among many other things. The configuration we usually use is the one mentioned at the end of the article "30min setup" (https://resources.taiga.io/30min-setup/)

server {
  server_name taiga.mycompany.com;

  ...

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect off;
    proxy_pass http://localhost:9000/;
  }

  # Events
  location /events {
      proxy_pass http://localhost:9000/events;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_connect_timeout 7d;
      proxy_send_timeout 7d;
      proxy_read_timeout 7d;
  }
}

For example, we use this for an staging enviroment with ssl cert.

server {
  listen 443 ssl;
  server_name staging-taiga.example.com;
  client_max_body_size 100M;

  ssl on;
  ssl_certificate /etc/nginx/ssl/cert_fullchain.pem;
  ssl_certificate_key /etc/nginx/ssl/cert.key;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers  HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers   on;

  access_log /var/log/nginx/staging-taiga.access.log;
  error_log /var/log/nginx/staging-taiga.error.log;

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect off;
    proxy_pass http://taiga6/;
  }

  # Events
  location /events {
      proxy_pass http://taiga6:8888/events;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_connect_timeout 7d;
      proxy_send_timeout 7d;
      proxy_read_timeout 7d;
  }
}

I hope this can help you.

Best regards

--
Please help us keep the Taiga.io Community open and inclusive, follow our Code of Conduct:
https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
---
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/ac4d6489-f503-46a6-9976-4b0a2d40f8fen%40googlegroups.com.

--

	David Barragán Merino Engineer & Co-founder  kaleidos.net/FFF8E7

Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, y pudiendo contener información confidencial sometida a secreto profesional, o cuya divulgación esté legalmente prohibida. Cualquier opinión en él contenida es exclusiva de su autor y no representa necesariamente la opinión de la empresa. Si ha recibido este mensaje por error, le rogamos nos lo comunique de forma inmediata por esta misma vía y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. El correo electrónico vía Internet no es seguro y no se puede garantizar que no haya errores ya que puede ser interceptado, modificado, perdido o destruido, o contener virus. Cualquier persona que se ponga en contacto con nosotros por correo electrónico se considerará que asume estos riesgos. KALEIDOS OPEN SOURCE se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente del mismo. INFORMACIÓN PROTECCIÓN DE DATOS. Responsable: KALEIDOS OPEN SOURCE (B86241973) Le informamos que sus datos identificativos y los contenidos en los correos electrónicos y ficheros adjuntos pueden ser incorporados a nuestras bases de datos con la finalidad de mantener relaciones profesionales y/o comerciales y, que serán conservados mientras se mantenga la relación. Si lo desea, puede ejercer su derecho a acceder, rectificar y suprimir sus datos y demás reconocidos normativamente dirigiéndose al correo emisor o en los datos del responsable. Para información y consultas visite nuestra web  https://kaleidos.net

[David Barragán]

Just an appreciation, in our case taiga-gateway serves on port 80 (the frontend, the api and the media, protected, files) and events on the 8888, so we use those values to define the proxy_pass. In the example code of the article, it is expected that both will be served on port 9000, the default configuration, which is what is used in the proxy pass in that case.

[Quentin Jackson]

Hi and thanks for your help.  Yes, I think this is exactly what my comment is about.

The example you list below first says that the external proxy is talking to local host which to me means it’s not an example for an external proxy at all, rather for the nginx that comes within the default docker-compose.yml.  If this is not correct, then should the example not be using something other than localhost?  I think this is confusing things quite a lot as external gateways would most definitely not be communicating with localhost.

Also, I’m still trying to understand does your external nginx in this common scenario talk to your internal nginx or not?  Because what you have here is what I already have and while taiga works, the events portion does not.  BTW when I say events, I am specifically looking for the functionality that a moved card moves on all accounts logged in to a sprint so that people can collaborate.  Presently a browser refresh is required.

My external nginx config is below (note some things taken out as they exist in /config/nginx/proxy.conf listed underneath).  BTW for some reason I could not get this to work with port 9000 nor with 80 which would have been my preference, so this 443 is a terrible example given it is not ssl at all on the taiga side.

server {

    listen 443 ssl;

    listen [::]:443 ssl;

    server_name taiga.memorycradle.com;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    large_client_header_buffers 4 32k;

    charset utf-8;

    # Frontend

    location / {

        include /config/nginx/proxy.conf;

        resolver 127.0.0.11 valid=30s;

      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

         proxy_pass http://192.168.43.18:443;

    }

  # Events

  location /events {

      proxy_pass http://192.168.43.18:8888/events;

      proxy_set_header Upgrade $http_upgrade;

      proxy_set_header Connection "upgrade";

      proxy_connect_timeout 7d;

      proxy_send_timeout 7d;

      proxy_read_timeout 7d;

    }

}

client_body_buffer_size 128k;

#Timeout if the real server is dead

proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Advanced Proxy Config

send_timeout 5m;

proxy_read_timeout 600;

proxy_send_timeout 240;

proxy_connect_timeout 240;

# TLS 1.3 early data

proxy_set_header Early-Data $ssl_early_data;

# Basic Proxy Config

proxy_set_header Host $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 https;

proxy_set_header X-Forwarded-Host $host;

proxy_set_header X-Forwarded-Ssl on;

proxy_redirect  http://  $scheme://;

proxy_http_version 1.1;

proxy_set_header Connection "";

proxy_cache_bypass $cookie_session;

proxy_no_cache $cookie_session;

proxy_buffers 256 16k;

proxy_headers_hash_bucket_size 128;

proxy_headers_hash_max_size 1024;

I am just trying to get clarity on the logical architecture of it.

Can you confirm:

1 - Existing company NGINX —> Default Taiga Nginx (gateway) —> frontend / events

Or

2 - Existing company NGINX —> frontend / events (i.e. removing the gateway that comes with taiga).

Many thanks,

Marshalleq

[Marshalleq]

So another day and another failure trying to get this to work.  I just don't get what I'm missing.  I did find what I think is an error in the default code:  TAIGA_WEBSOCKETS_URL: "ws://taiga.yourdomain.com:443" should have wss not ws right?  I saw it in another persons example config - and if I have it as ws most browsers won't connect, changing to wss seems to fix it.

I've today just tried doing NGINX --> Frontend / events etc, but that didn't work.  I don't know, it shouldn't be this hard.