Riotkit Taiga behind SSL proxy via Apache RewriteRule works. Almost.

24 views
Skip to first unread message

David Zejda

unread,
Nov 30, 2020, 6:04:29 PM11/30/20
to taigaio
Hi, first of all, many thanks for all your hard work on taiga!

I have been succesfuly running the riotkit docker version (https://github.com/riotkit-org/docker-taiga) on plain HTTP for some time. In my config, the docker taiga has its own public IP and so far, the domain name was pointed to this IP.

As a next step, I wanted to put this cherished instance behind SSL.

To do so, I changed the DNS to point to the IP where a separate Apache is sitting (outside of docker, but on the same box) and configured Apache to act as a reverse proxy. The proxying is defined by this simple rule:

RewriteRule (.*) http://<TAIGAIP>:80/$1 [L,P]

With <TAIGAIP> replaced for the public IP served by the nginx within the taiga docker.

In riotkit .env config I changed only:

TAIGA_SCHEME=https

and restarted everything. Now I can access the taiga instance via HTTPS, which is great. Amazingly simple.

However, the joy was short-lived, because of the following problem which is resisting my efforts:

One user thumbnail picture is still being requested by taiga source via HTTP (though eventually loaded by HTTPS because of the Apache proxy intervention), leading to the "mixed content" browser complaint about HTTP mingling with HTTPS.

What is weird - all other contents, including all other image thumbnails, are being loaded via HTTPS. The problem persists even with cache disabled completely by browser developer tools.

In the subsequent investigation, since I don't have the credentials of the user whose picture is causing the problem, I even tried to remove any reference to this particular misbehaving picture straight from the database (tables users_user, thumbnails_thumbnail, thumbnails_source - I did not find it being mentioned anywhere else). However, the picture is still being loaded, leading to "mixed content", aargh. Why so, if it is no longer referenced by the database? Could some kind of server-side cache be in play?

When I tried to remove the image physically from the docker volume, still it is being asked by taiga program, leading to 404 error reported in browser developer tools in addition to the "mixed content" browser complaint. 404 is understandable, but no progress regarding the problem.

Furthermore, the misbehaving image is not used anywhere on the page - it relates to a user associated with a different project than the one being shown.

This is the part of browser developer console stacktrace related to the HTTP fetch attempt:

attr @ jquery.js:4103
ke @ jquery.js:141
attr @ jquery.js:4103
(anonymous) @ app.js:26994
...


It is pointing to app.js file, the modules/user-settings/notifications.coffee section, namely to:

module.directive("tgUserNotifications", UserNotificationsDirective);

UserNotificationsListDirective = function($repo, $confirm, $compile) {
  var link, template;
  template = ... (removed)
  link = function($scope, $el, $attrs) { <---- this line


Please, any idea how to solve this mystery?
Would be greatly appreciated!

Regards,
David
Reply all
Reply to author
Forward
0 new messages