I am experiencing a similar situation to what is described at BOA-2.0.9 redirects HTTPS admin/edit requests to homepage on D6 due to differing Session IDs, but there are a couple significant differences, so I'm creating a separate issue. Also, because the other issue was changed from bug report to feature request and because it is not repeated on my other sites, I'm not ready to say this is a bug.

The behavior is the same as described in the other issue: Once logged in as user 1, none of the edit and admin page links will deliver the correct page. Instead, the site redirects to the home page.

The problem appears on a D6 site, but the differences in my case are that no https URLs are involved and the Session 443 module is not being used.

One more difference: Comment #1 of the other issue says a work around is to use non-clean URLs. This does not work as a workaround on my site.

It should be added here that I am running two other D6 sites on the same BOA server, but the others are running on different Octopus instances. Neither of the other two sites exhibit the same behavior. I am able to browse to /admin and /edit pages with no problem.

Log files and octopus.cnf file can be found here.

Comments

snlnz’s picture

snlnz CreditAttribution: snlnz commented

Should be the same resolution as: 403 for anonymous users on node/add

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented

This applies to my situation? It refers to anonymous users. I'm experiencing the problem with User 1 (admin) and it's not just with node/*/edit.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Component: Nginx Configuration » Code

All Octopus instances use the same /data/conf/global.inc file, so it sounds like something site specific then if the issue doesn't affect all instances. This obviously means that our ability to provide assistance in debugging this is limited. In short - this shouldn't happen, unless there is a module or code which alters Drupal sessions handling.

Also, are all those Octopus instances at the same version?

Note that the access control for /admin moved to the /data/conf/global.inc works only when you upgrade Octopus instance to head, because BOA-2.0.9 still includes Octopus from 2.0.8, so Nginx configuration is not updated to reflect these changes, unless you will upgrade Octopus to head.

Then you should try to use the control files introduced:

sites/foo.com/modules/disable_admin_dos_protection.info
sites/foo.com/modules/allow_anon_node_add.info

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented

The instance that is causing problem with the D6 site at one time also contained a D7 site that contained some modifications for an SSL certificate. Later, the client chose to move the site to an omega8.cc server, so the SSL cert setup was no longer needed. This is the only thing that I can think of that is different about the instance from the others, but given that the cert configuration is based on the site and not the instance, I'm not seeing how that would matter.

To answer the question about Octopus versions, yes, they were all updated on the same day. This raises another question. The three different instances show the same configuration in their octopus_log.txt files.

 Sat Jun 22 12:48:03 EDT 2013 / Debian.squeeze i686 / Aegir BOA-2.0.8 / Octopus BOA-2.0.9 / FPM 5.2 / CLI 5.2

Should I upgrade the Octopus instance to HEAD? Or am I better off just moving the problem site to a different instance? I'd like to take the easiest, cleanest route to fix this,. My client is patient, but I would like to resolve the problem as quickly as possible.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Component: Code » Miscellaneous
Status: Active » Closed (works as designed)

If there is no 403, then it has nothing to do with Nginx configuration on the Octopus instance level. It is a result of cookie name miss-match, and you can easily check and compare it by looking into headers with curl -I domain/user. You can also easily disable this check/protection/redirect with control files, as suggested by Grace in the comment #3 above.

I think this issue can be safely closed. Feel free to re-open if you will find anything BOA (and not the site) related, which should be investigated more.

~Robert

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented
Status: Closed (works as designed) » Active

Thank you for the response, Robert. It might very well be a site-specific problem, but from your answer I'm not sure you are understanding my problem. Or maybe I'm not understanding something fundamental here.

To be clear: My problem does not involve anonymous users, only authenticated users with administrative privileges.

Based on what I understand, it would seem that using curl -I will do me no good for trying to see if an admin page is delivering a 403 improperly for a logged-in administrator. Administrative pages will always deliver a 403 from Curl (without a script to log in). Similarly, using an allow_anon_node_add.info file will do me no good if I don't wish for anonymous users to create or edit content.

Am I missing something? If so, I apologize. Perhaps I'm just being dense or stubborn, but I'm marking this "active" to take one more stab at it. If you think I have been given all of the information that applies, feel free to mark again as closed.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented

I understand this very well, I think.

There is no 403 here - you are saying about redirect, not a 403.

The curl -I test will reveal the domain used for the cookie, so we could see if there is any mismatch between domain used for the cookie and the server name, no matter if you are logged or not - did you notice the URL to test in my comment above? It has nothing to do with /admin

And yes, it doesn't help if you are logged in as uid=1 if the test in the global.inc says that your cookie is not valid or at least non-standard and thus redirects you to the homepage.

Have you tried to use the control files to disable this protection?

Please try sites/foo.com/modules/disable_admin_dos_protection.info as suggested and then try to debug further on a copy of the site, to avoid causing issues for your client.

~Robert

JimSmith’s picture

JimSmith CreditAttribution: JimSmith commented

Again, thank you for your patience and assistance, Robert.

I resolved this problem, but it was not through the use of a sites/foo.com/modules/disable_admin_dos_protection.info file.

I could not find a mismatch in cookie names using curl -I. When I took a look at local.settings.php, however, I discovered it contained a line to set the cookie domain (I have sanitized the domain name):

<?php # local settings.php
$cookie_domain = 'mydomain.org';

Commenting out the $cookie_domain line fixed the problem.

Until this moment I had forgotten that this line was added due to an issue with CKFinder, as described in $cookie_domain not defaulted properly on CKFinder boostrap.

This proves the problem is site-specific, but now leaves me pondering whether I need to tell the client we need to find a substitute for CKFinder or if there is another workaround.

omega8cc’s picture

omega8cc CreditAttribution: omega8cc commented
Status: Active » Closed (works as designed)

The curl -I test for sure displayed the (expected) value of $cookie_domain in the X-Cookie-Domain header, so it should help in debugging - but if you have set $cookie_domain in the local.settings.php without the required, leading dot, then no wonder it caused issues.

If you have unrelated here problem with CKFinder, please open separate issue.

HTH
~Robert