Front page redirected you too many times

I recently migrated from 5.2.4 to 5.2.5 and with the new version can't open the front page as anonymous. The browser says

This page isn’t working.
localhost redirected you too many times.
Try clearing your cookies.

All the other pages can be opened and work as expected. The front page is published (=expected to be seen by anonymous).
The browser cookies are cleared.
The front page is made from the standard dexterity Page. Only standard portlets are there.
If I first login from ZMI then this problem disappears.
These two lines are printed many times in instance-access.log:

"GET /cl/acl_users/credentials_cookie_auth/require_login?came_from=/cl HTTP/1.1" 302 0 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36"
"GET /cl/login?came_from=/cl HTTP/1.1" 302 476 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36"

The instance is installed on a remote machine where I connect to via ssh local port forwarding. No HTTP servers between us.
Migration to 5.2.6 does not resolve the problem.
I need help to track and solve it.

Apparently, your front page redirects to itself.

At your place, I likely would put a breakpoint on ZPublisher.HTTPResponse.HTTPResponse.redirect and check in the debugger where it is called from.

I would check the real permissions in the ZMI. Then create a new page and set it as home to see if happen again. If it does not happen, make a copy of the not working page content.

I would check the real permissions in the ZMI. Then create a new page and set it as home to see if happen again.

I have tried that - still redirects.

Control Panel -> url management. Try to download the csv and see if there are some redirects that involve /. But that would happen also before the migration.

Can you also access /cl/login (no came_from parameter) without been redirected somewhere?

Thanks for your ideas @yurj.
/cl/login redirects as well:

"GET /cl/acl_users/credentials_cookie_auth/require_login?came_from=/cl/login HTTP/1.1" 302 0
"GET /cl/login?came_from=/cl/login HTTP/1.1" 302 476

I have also noticed that while I can login via ZMI I can't do it from the web site. Pressing the Log in link brings this message:

localhost:8081 says
There was an error loading modal.

(ok, i've got this link points to the same/cl/login :slight_smile: )

No redirects involving / in the URL management.

This is a javascript error.
Usually, you can fix this by

  1. Disable the theme
  2. Enable debug mode (@@resourceregistry-controlpanel)
  3. Go to some page
  4. Enable the theme
  5. Disable debug mode
  6. Reload a page 'once or twice'.

@espenmn : the problem does not disappear when I apply your suggestions and even if I disable the theme.

@dieter :

At your place, I likely would put a breakpoint on ZPublisher.HTTPResponse.HTTPResponse.redirect` and check in the debugger where it is called from.

I put pdb.set_trace() as a first line of the redirect method.
It looks like it's called by CookieAuthHelper. What can I do to fix it?

The redirect comes from the challenge method. This means that the object is not accessible for anonymous -- despite your expectation. The problem may be global (caused by the permissions of the selected view) or local (caused by an access to a protected object). To check the first case, look in the debugger at request["PUBLISHED"].__roles__ (if request["PUBLISHED"] is a method, use request["PUBLISHED"].__self__.__roles__ instead). It tells the roles for which access to request["PUBLISHED"] is granted. The check the second case, you activate verbose-security and reconfigure your error_log (not to ignore Unauthorized); this should provide detailed information in your error_log.

Apparently, you have a second problem: the challenge redirect usually redirects to the login page which should be viewable for anonymous. In your case, this is either not the case or the challenge URL is wrong; verify the URL in the debugger. You can make the checks above for the login page as well to determine whether it is a global or local permission problem.

Please check for javascript errors (I have had this error tens of times and have always managed to fix it in 'similar ways as I described' (maybe more reloading and different order of things')

If there are no errors: Is it possible that you have overridden the login page or similar ?

The problem is solved. When I included the Unauthorized exception type as suggested by @dieter I've got these messages in the error log:

Your user account does not have the required permission.
Access to 'aggregator' of (Folder at /cl/events) denied.
Your user account, Anonymous User, exists at /acl_users.
Access requires View_Permission, granted to the following roles: ['Contributor', 'Editor', 'Manager', 'Owner', 'Reader', 'Site Administrator'].
Your roles in this context are ['Anonymous'].

Changing the state of the events/aggregator collection from private to public solved the problem. Still do not understand why I did not have redirections from the other pages then (I have the Events portlet on each page), but it looks like everything works fine now.
Thank you @dieter, @espenmn and @yurj for your help!

1 Like