Bug #85766

redirect back to issue when logging in from the issue single view

Added by Tymoteusz Motylewski about 3 years ago. Updated over 2 years ago.

In Progress
Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:


After recent upgrade to newer redmine, the redirect stopped working.

How to reproduce:
- Open an issue, e.g. https://forge.typo3.org/issues/85764
- click login in the right top corner
- fill login data
- you're now redirected to your profile page "my page"

I would expect to be redirected back to the issue (and this was how it worked before the upgrade).

It;s quite annoying when for everybody who maintain issues on forge, or just want to comment sth.


Screen-Shot-2018-08-14-at-17.09.png (26.7 KB) Screen-Shot-2018-08-14-at-17.09.png Steffen Gebert, 2018-08-14 17:11
direct.txt (1.35 KB) direct.txt Steffen Gebert, 2018-09-04 06:33
proxy.txt (1.35 KB) proxy.txt Steffen Gebert, 2018-09-04 06:33

Updated by Steffen Gebert about 3 years ago

Well, we had a custom authentication logic before, now we use core redmine. Seems this just do it. So I guess this likely a "won't fix", except somebody comes up with a plugin / solution.


Updated by Steffen Gebert about 3 years ago

  • Status changed from New to Needs Feedback

Updated by Tymoteusz Motylewski about 3 years ago

I've played around with redmine.org, and checked that there I'm getting correctly redirected back to the issue page.
I've also tested that after removing all cookies. There is no url parameter, the request goes via GET, so I think redmine us using referer header for redirect.
Could it be the case that referer header is stripped somewhere in the proxy before getting to redmine?
I know this is a long shot, but worth checking before we put the issue aside waiting for the cavalry ;)



Updated by Tymoteusz Motylewski about 3 years ago

I've also checked with guys on the redmine support chat (https://discord.gg/tHgdVSj) and they have confirmed that vanilla redmine redirects you back to the previous page after login.


Updated by Steffen Gebert about 3 years ago

Oh, that's interesting. Well done research, I really appreciate this!

And you were totally right (which I can't believe..). It works with circumventing the proxy!

This is our proxy config:

server {
  listen 443 ssl http2;
  listen [::]:443 ssl http2;
  server_name forge.typo3.org;

  access_log /var/log/nginx/forge.typo3.org-access.log combined;
  error_log /var/log/nginx/forge.typo3.org-error.log;

  add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload;";
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options SAMEORIGIN;
  add_header X-XSS-Protection "1; mode=block";

  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header HTTPS on;
    proxy_set_header Proxy "";
    proxy_redirect off;


And this here the template for the nginx calling the thin application server.

Anyone with some idea?


Updated by Tymoteusz Motylewski about 3 years ago

would adding

proxy_set_header Referer $http_referer;



Updated by Steffen Gebert about 3 years ago

I see the `referer` header being correctly set on the backend server when capturing traffic with tcpdump.

Would say it's something different..


Updated by Tymoteusz Motylewski about 3 years ago

Thanks for checking.
Did you check whether there is a difference in the Http request when doing the request directly to a server and through a proxy?


Updated by Steffen Gebert about 3 years ago

Hi, sorry for not coming back to this earlier. I've attached the HTTP traffic recorded at that redmine server.

The setup is as follows:

In production (file proxy.txt), we have an nginx proxy server (pair) running in front of our backend servers, taking over TLS termination. So on redmine, this traffic arrives at port 80 (thin application server) and was captured there. The redirect does not work there.

For a test (direct.txt), I've updated my /etc/hosts to send forge.typo3.org directly to the redmine server via plain HTTP. The redirect does work there.

From attached files, I can't see any obvious difference - besides the headers that the proxy adds:

X-Forwarded-For: 89.12....
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Real-IP: 89.12....

Tymoteusz has yesterday sent me the link to the authentication code in Redmine.

The interesting part starts here in redirect_back_or_default, which later calls validate_back_url containing the following lines

[:scheme, :host, :port].each do |component| if uri.send(component).present? && uri.send(component) != request.send(component) return false end uri.send(:"#{component}=", nil) end

I think this is the reason, why it does not work with the proxy (hopefully LDAP auth doesn't execute any other code..).

When comparing the back_url given with the current request, the following

scheme host port
back_url https forge.typo3.org 443
request http forge.typo3.org 80

So at least assuming that the request object does not take proxy headers into account in Rails/Redmine, this code would abort the redirect process. Can somebody with Rails/Redmine knowledge confirm this?


Updated by Bastian Bringenberg over 2 years ago

  • Status changed from Needs Feedback to In Progress
  • Assignee set to Bastian Bringenberg

Checked this on my local 3.4 instance and it worked even behind a nginx reverse proxy with the same settings. Will verify it working after 3.4 deployment.

Also available in: Atom PDF