Error in redirect after login in old instance 2.4.13

<%- if @topic_view.topic.tags.present? %>
<%= t 'js.tagging.tags' %>: <%- @topic_view.topic.tags.each do |t| %> <%= t %> <%- end %>
<% end %>

SS_2.4.13

By relocating the old instance to a new server (migration to SS4.7 ist the next step) I am not able to login in cms. After enterring the credentials there is a redirect to Security/login. Is there any idea where this redirect comes from?

Details: our planned migration to 4.7.2 is done be building up a complete new site. We will move selected content from the old instance manually and will not migrate all stuff. We started to build up two containers - one for the old, the other for the new instance, behind a traefik-reverse-proxy including certificates from letsencrypt. Inside the container for 2.4.13 we use the same old ubuntu, lighttpd and php versions. This container will be shtudown completely if the new site is finished. Meanwhile, we want to use the old instance as container.
In dev, everything works fine inside the container (including cms-login), but on our productive server, the cms-login does not work. I see differences in the request/response between prod and dev (also old-server). Prod responses in http/2, dev and old-server in http/1.1. There is also an additionally value “location” in the http/2-response (in prod) and I have no glue where this comes from. Is there any idea how to keep the container for the next month until the migration is finished?

Best regards,
chrclaus

I debugged the request processing looking forward to the line of code, where the redirect is initiated. In LeftAndMain::init I got a Security::permissionFailure with the message “Please choose an authentication method and enter your credentials to access the CMS.”.

It´s a complete copy from the old server, including the database export. There were n changes made to any authentication methods. Does anybody has an idea?

Best regards,
chrclaus

Is the site running over https? (I’m guessing it is because you mention LetsEncrypt)

If so, then it’s quite a common issue with sites behind a load-balancer / proxy if the internal traffic is non-secure. Is the web instance using https as well?

Are the PHP versions on your dev server and production server?

The common issue you mentioned is interesting, do you have more details to it?

You are right, the site is running over https: the old/existing site obtains their certificates from letsencrypt via certbos scripts. At the migrated site a traefik-rev-proxy takes all the stuff around certificates via dns-01 challenge and wildcard-certificates.
For eleminating these topics i stopped traefik and started two single container for silverstripe_2.3.14 and mariadb. There is lighttpd running in the container an i put the existing and still valid certificates inside this container. Thats working, despite the CMSLogin.
As i mentionen we lilf&shift the old instance in a container for the meantime of the migration. We run lighttpd 1.4.33 with php 5.5.9 on ubuntu 14.04. I´m aware of the security issues and thats the reason for the (too-late) migration.

I´m not sure about your question

Is the web instance using https as well?

The DIRECTOR_SETBASEURL is set to https://www.mydomain.com/. Was this your intention?

I made another interesting observation. By debugging the login-process, the underlying member-object is determined correctly. After this successful login, the redirect to /admin/show/1 is triggered. But in LeftAndMain::init the Member::currentUser() is empty - probably the session-information are dumped. Therefore the permission-check canView() for the menu-items fails due to the absence of the member object which results in the missing authenticator-error-message.

Since there were no changes to the code before the lift&shift-operation I believe more and more in differences of a php-parameter between these two instances …

It seems, I got two session-id´s …

Is this the reason for the redirect to Security/login?

RESOLVED:
Afaik the problem was indeed in the second session-id. I had to set the base_url to fqdn including https for loading all ressources via https. By doing this, the cookie_domain and cookie_path were not set correctly. The solution was simply adding:
Session::set_cookie_domain('www.tgcamberg1848.de');
Session::set_cookie_path('/');
in ./mysite/_config.php I do not understand why the old instance works fine but I´m happy with this intermediate solution.

Best regards,
chrclaus