ERR_TOO_MANY_REDIRECTS

[Aido]

Hi,

User gets this error ERR_TOO_MANY_REDIRECTS in the browser if he tries to access to the page to which he does not have a permission.

Regards,
Eugene

PS It looks like you have a certificate issue on your domain

[mudmin]

I don't know what the deal was with the certificate issue. We had 60 days left on our cert. Weird.

So the too many redirects has to do with where the user is being redirected. If you accidentally secured a page that you were trying to redirect the person to, you would get in a loop.

What version are you using?

[mudmin]

Hi,

User gets this error ERR_TOO_MANY_REDIRECTS in the browser if he tries to access to the page to which he does not have a permission.

Regards,
Eugene

PS It looks like you have a certificate issue on your domain

A few more things. Thank you so much for telling me about the certificate.

1. Is the page the user's trying to visit set with the "require reauth" checkbox on the page manager? It's possible the person doesn't have access to that page.
2. Does the user have the "user" permission?  Every user should have it even if you give them other permissions.  
3. If they do have the user permission, did you mess around with any pages, possibly taking the user permission away from that page?
4. Did you modify anything in the usersc/scripts/did_not_have_permission.php script?

[Aido]

A few more things. Thank you so much for telling me about the certificate.

1. Is the page the user's trying to visit set with the "require reauth" checkbox on the page manager? It's possible the person doesn't have access to that page.
2. Does the user have the "user" permission?  Every user should have it even if you give them other permissions.  
3. If they do have the user permission, did you mess around with any pages, possibly taking the user permission away from that page?
4. Did you modify anything in the usersc/scripts/did_not_have_permission.php script?

1. "require reauth" is not set for the page he tries to visit but where he should be redirected in this case?
2. Yes I deleted the users' permission first but now I returned it but the issue is still here.
3. I am sorry from what page? the page he tries to visit? it is a new my page I don't plan to give access to this page to users. I have a special role for this page.
So it is ok that he has no access but he must be redirected to the home page or somewhere else but he gets the error
4. No, I did not.

---

the version is 4.4

[mudmin]

1. I believe it is users/admin_verify.php, which is usually something that has admin only access.
2. To explain 2 and 3 together, if a regular user is logged in and does not have permission to view a page, they should be redirected to users/account.php by default. Sorry, I should know that off the top of my head, but I didn't I'm coding another project at the moment and didn't have time to check.

So, the big question is, does the user that is being redirected, have the proper permissions to visit account.php? If not, they will wind up in a redirect loop.

[mudmin]

If you're on 4.4, you should be able to go to tools->security logs and see what pages that user was bumped from. You can check to see if they have permission to view those pages. If you're on 4.3.x, it's usersc/tomfoolery.php but I forget what that link is called on the dashboard.

[Aido]

I checked the Security log - it looks like the user, again and again, try to get access to the initial page. No other pages in the log.

This user has user permission level and this level has access to users/account.php

[Brandin]

What page are they trying to visit? Is this a custom coded page?
Do you have any redirects written in code ON the page within things like if statements or just straight up?

[Aido]

What page are they trying to visit? Is this a custom coded page?
Do you have any redirects written in code ON the page within things like if statements or just straight up?

Yes it is a custom coded page
it uses many require statements but no redirects as I know

Also, I don't know is it important or not I have the following error in the console for most pages

fingerprint2.js:539 Uncaught TypeError: Cannot read property 'appendChild' of undefined

    at fingerprint2.js:539

---

Dear Brandin,
I think I know the reason but I don't know the solution.

1. My folder structure looks like this
/users/...
/usersc/...
/index.php - root project page
...
/r/reports/report_1/index.php
/r/reports/report_1/reportfile1.php
/r/reports/report_1/reportfile2.php
...
The start point for the report and the page which I set the permission is /r/reports/report_1/index.php

I've performed a small test - i created a very simple php file with userspice headers and just phpinfo() inside and set the same permission as my problem page.

/r/reports/report_1/test.php

The issue has repeated but I noticed that I was redirected from /r/reports/report_1/test.php to /r/reports/report_1/index.php.
So it looks like if the user has no access to the file he is redirected to the index.php in the same folder.
I think it is because of my Redirect After Login setting that is /index.php but I cannot change it to another page because I would like that the first page for users was the project page... I am surprised that this setting has another effect.

[Brandin]

That setting should not create the impact. The securePage function should be called which is what triggers a user to get redirected without permissions. Please review the securePage in users/helpers/us_helpers and see if you can find the redirect in there. Overall, the fact still remains that when you are calling the securePage function, it is thinking they don't have permission.

The only other things that trigger forced redirects are:
users table: oauth_tos_accepted=0 (redirects to users/oauth_success.php
settings: admin_verify=1, page is re_auth=1 and the user does not have access to admin_verify.php
maintenance mode: site_offline=1 in settings, user does not have access to maintenance.php in users, it should be set to public

I can't think of many more hard redirects we have setup that would trigger these issues.

Thank you,
Brandin.