New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tine20 login page stuck loading when placing nginx reverse proxy in front of tine20 apache. #6994

Closed
talsen-team opened this Issue Feb 8, 2019 · 13 comments

Comments

Projects
None yet
3 participants
@talsen-team
Copy link

talsen-team commented Feb 8, 2019

Hi tine20 community,

the problem

When tine20 docker container is ready to use via http and an nginx reverse proxy is put front of the tine20 apache server, the login page gets stuck loading for ever (in Firefox and partly in Chromium).

The desired infrastructure setup is visualized below:
images/infrastructure-setup.png

how to reproduce

Visit this repository and follow the instructions.

my request

Can you help out with the nginx configuration.
I'm not a reverse proxy expert, neither do I know tine20 good enough to detect the reason for the described problem.
Hopefully you can detect the fault, otherwise the docker setup is quite useless for us. :)
Thanks, in advance !!

edit 2019-02-10 09:07

Here are links to the nginx configuration and the apache2 configuration files.

@lab-at-nohl

This comment has been minimized.

Copy link
Contributor

lab-at-nohl commented Feb 9, 2019

Hi, I don't have a solution. But it would be helpful to see a log file (level DEBUG, configured in config.inc.php). Generally your setup should work.

As you have Apache and PHP in your container you will probably do URL-rewrites with Apache (see this repository, tine20/docs/). Otherwise, if your container only includes php-fpm, you need to do rewrites with your nginx front server. Most probably you need to set some environment variables in nginx and/or set tine20url in config.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 10, 2019

Here are the log files of both web servers nginx and apache2 and the tine20 log as well attached for the used domain name https://localhost (which can be correctly displayed by Chromium but not by Firefox).
nginx-access.log
nginx-error.log
apache2-access.log
apache2-error.log
tine20.log

In the apache2 error log the entries
[Sun Feb 10 09:13:27.711202 2019] [core:error] [pid 999] [client 172.18.0.1:41772] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: https://localhost/
look suspicious, but I do not have an idea why that redirection loop happens or how to get rid of it.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 10, 2019

Here are the log files of both web servers nginx and apache2 and the tine20 log as well attached for the used domain name https://tine.private
nginx-access.log
nginx-error.log
apache2-access.log
apache2-error.log
tine20.log

The error
[Sun Feb 10 09:46:09.758023 2019] [core:error] [pid 1000] [client 172.19.0.1:55754] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: https://tine.private/
in the apache2 log still persists.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 10, 2019

FYI:
The above mentioned apache2 error also occurs when using the native installation with apt-get, where apache2 handles the http to https redirection (I just checked).

Regarding the hint Use 'LogLevel debug' to get a backtrace.: I'll check that later today or during the early next week (Monday, Tuesday).

@lab-at-nohl

This comment has been minimized.

Copy link
Contributor

lab-at-nohl commented Feb 10, 2019

Hmm, I can't identify anything in your logs. Are you sure that your tine20.log only includes the failing request (it seems to be configuration). I can only guess.

Generally, there is a variable for config.inc.php 'trustedProxies' => array ("xxx.xxx.xxx.xxx"), which might be useful. But again, I can't say it for sure. Maybe you look into your Browser console, too. Because there might be a hint like forbidden CORS request or similar.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 11, 2019

I used the Chromium Developer Console and detected the following error messages:
Mixed Content: The page at 'https://tine.private/' was loaded over HTTPS, but requested an insecure script 'http://tine.private/Tinebase/js/fatClient.js-c79fcf9f7cddb7b5e69e-FAT.js'. This request has been blocked; the content must be served over HTTPS. (index):1 Mixed Content: The page at 'https://tine.private/' was loaded over HTTPS, but requested an insecure script 'http://tine.private/index.php?method=Tinebase.getJsTranslations&locale=en&app=all&version=ce92dfccacd6bf202116c419e856ffea17b37604'. This request has been blocked; the content must be served over HTTPS.

It seems that nginx does not redirect the http requests for some reason.

@lab-at-nohl

This comment has been minimized.

Copy link
Contributor

lab-at-nohl commented Feb 11, 2019

You should ask for help in a nginx forum, at least I can't help. But this does not to be Tine 2.0 specific. In Apache there is ProxyPassReverse to avoid such answers. Edit: Try to set tine20url to the outside URL including https, this might affect how js is delivered.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 11, 2019

I just created a question on stackoverflow. ;-)

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 12, 2019

The above mentioned issue was resolved setting the tine20URL property in the /etc/tine20/config.inc.php file to the value https://localhost.
The issue branch for the docker repository has updated to use the correct configuration (line 194) now.

edit on 2019-02-13 11:45 AM:
The above mentioned issue was resolved setting the tine20URL property in the /etc/tine20/config.inc.php file to the value https://<your-tine20-url>.

@lab-at-nohl

This comment has been minimized.

Copy link
Contributor

lab-at-nohl commented Feb 13, 2019

This cannot work because all links are broken then (e.g. Invitations/Reminders fo externals point to localhost). But your problem seems to be identified. Please look at #6991.

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 13, 2019

I fixed the comment above. Is it correct now?
Because at least the web UI works fine now with docker.

@paulmhh

This comment has been minimized.

Copy link
Contributor

paulmhh commented Feb 13, 2019

yes: for the meantime setting the 'tine20URL' config will help as a work around

the fix to make it work even without setting that config will be part of the next release

@talsen-team

This comment has been minimized.

Copy link
Author

talsen-team commented Feb 13, 2019

Ok thanks for your help :)
We'll try the docker setup and report how it works ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment