Too many redirects ( WAS - SSL Proxying not enabled for this host)

This is not enough information. Please follow bug submission guidelines: http://drupal.org/node/add/project-issue/barracuda

Thanks.

Note that you should *never* upgrade Drupal core with Drush!

You can use BOA head which includes D 7.9 already.

Also, where do you see this error? Some screenshot would help probably.

Charles?

Sorry, we can't help if you don't provide enough information about your environment and system/network configuration.

Please provide exact steps to reproduce the issue, with URLs to test etc.

Make sure you don't have internal Aegir SSL feature enabled and there is no module causing unexpected redirects.

Could you disable this Charles proxy and simply access the site directly?

Also, please provide steps to reproduce the issue, as I requested above.

I'm sure you have some module or setting in your site which causes the extra redirects (loop). It is *not* BOA issue.

This redirect to HTTPS is not caused by the proper extra settings in the global.override.inc file. What you did there doesn't make any sense, sorry. You should use the original configuration we provide in this file. Otherwise you are making your debugging impossible.

Could you please check *and disable* any other redirects you configured in your site?

I believe we can close this issue, because it is unrelated to BOA, rather to some wrong configuration in your site.

Feel free to re-open when you will find anything new after some real debugging, as suggested above.

I don't see here your comment I received via e-mail, so I'm posting it here:

"I must have missed the part when BOA stopped using the Aegir feature. I
have just now set the site to have encryption disabled. So I assume
that now there is a different way to enable ssl."

Have you read what I wrote in the #7 comment above? - "Make sure you don't have internal Aegir SSL feature enabled "

BOA *never* used Aegir built-in SSL feature. It is explained in the docs: http://drupalcode.org/project/barracuda.git/blob/HEAD:/docs/SSL.txt

No, properly used docs/examples will not cause any loops, as it will set the header correctly.

For single-IP server please read: http://groups.drupal.org/node/183789#comment-608709

It was probably enough to restart Redis/Memcached, not disable it. It is restarted every 30 minutes but you can also restart it manually: bash /var/xdrago/clear.sh

Probably, as it may still store your settings if you didn't use the clear cache button in Drupal etc.

pretty sure i'm having the same (or a very similar) problem.

i get the too many redirects issue until i visit /user, after which point the problem goes away until i clear my browser case. Then it breaks again.

subscribing.

for reference the discussion starts here: http://groups.drupal.org/node/187029

hey, is there any way that we can do this through an nginx config pushing everything from http to https? i'm getting no luck at all doing this via php, and it does seem to be because HTTP_X_FORWARDED_PROTO isn't always coming through.

@thedavidmeister - It is better to do that on the PHP level, and it gives you much more flexibility, it does work when done properly and when you don't use any stuff like Secure Pages module to introduce conflicts.

On the Nginx level it can be tricky (or even not possible). For example, you can't make it domain-specific with config like below, because Nginx doesn't support nested if():

if ($host ~* ^(domain\.com)$) {
  if ($scheme = http) {
    rewrite ^ https://$host/$uri&$args permanent;
  }
  try_files $uri @cache;
}

You would need to use extra location to separate the if() directives, but this will not work when SSL proxy (BOA standard) is used, as $scheme is always http in the server behind the SSL proxy and it will cause redirects loop:

if ($host ~* ^(domain\.com)$) {
  try_files @httpsonly =403;
}
location @httpsonly {
  if ($scheme = http) {
    rewrite ^ https://$host/$uri&$args permanent;
  }
  try_files $uri @cache;
}

As you can see, it is much simpler and more flexible on the PHP level.

Note - you could still enable Aegir native SSL support and then it will manage this redirect for you on the Nginx level (there is a "forced SSL" option), however then you will need to manually replace the SSL cert and key created by Aegir with your real cert and key. Plus, you will hit Aegir own limitations related to IP addresses management.

Thanks for the reply!

I have already replaced the cert and key with my own, as per the instructions posted elsewhere for wildcard certs.

basically, the problem is that I copied the exact example here:

http://drupalcode.org/project/barracuda.git/blob/HEAD:/aegir/conf/overri...

and replaced "domain.com" with the domain I'm using. Nothing else. Tried just using the bottom bit, tried using the whole thing.

Turned of Secure Pages. Turned off SSL management in Aegir. Cleared cache from within Drupal UI (not just through Drush).

the redirect does indeed work just fine but *only* when you've viewed the user page or logged in. Even if you log out again this will still work.

However, if you logout and clear your browser cache, or if you're a first time visitor, you'll get an infinite redirect loop.

turning OFF the redirect and trying print_r( $_SERVER ); just to see what is going on revealed that the HTTP_X_FORWARDED_PROTO is not set in the "preauthenticated" state for a user (and neither is $_SERVER['https'] btw), even when you view a page with https protocol. This obviously messes with the "if" statement since it will redirect to https constantly if that variable is not being set by NGINX before PHP starts playing around with it.

I have no idea why the header wouldn't be set, and beyond what I've described I don't know what else I could do to make sure the config is "done properly".

Incidentally, setting a redirect in NGINX to https worked fine, but (I think) because this didn't help those headers being set, Drupal generates pages with a bunch of http links in it, so I get security warnings for mixed protocol media all through my site. The redirect through NGINX was kind of a hollow victory in this case :(

Any ideas for things I could try to debug the issues re: sending the header info properly?

This is because HTTP_X_FORWARDED_PROTO is sent from the HTTPS proxy to the Nginx and PHP-FMP backend, while $_SERVER['HTTPS'] = 'on'; is set on the PHP-FPM level, to satisfy Drupal, if the request comes with HTTP_X_FORWARDED_PROTO header set to https. Note that HTTP_X_FORWARDED_PROTO header is sent to the backend only, and not to you with the response proxied from the backend to your browser.

When you are trying redirect on the Nginx level, you can't use any other redirects in Drupal or override.global.inc file. You should also disable, uninstall and remove any modules like Secure Pages - it is not enough to disable them.

Basically, don't try all these things at once. Don't use Secure Pages (uninstall and remove it) and use only our snippet in override.global.inc where you can easily manage which URLs should be forced as HTTPS and which as HTTP etc. It really works great and gives you full control without messing up your Nginx config. Just avoid redundant stuff lying around for redirects.

when you say "can't use any other redirects" do you mean literally all redirects?

what if i want to use the Global Redirect module, or I want to use a drupal_goto to send somebody to the latest posted node of a certain type from a menu link?

I do have some non-ssl related redirects in place and they're kind of important for the way I want the site to work and it would be quite time consuming to identify and remove all of them as a few different developers have worked on this project. Do I have to disable all of these as well?

Also, do i have to uninstall and remove the SSL modules in Aegir, or is it enough to just disable those?

uninstalling secure_pages instead of just disabling it seemed to do the trick, but I'm still a bit confused as to how all the caching stuff works. I thought I was across it but this issue leads me to believe that I'm not fully...

I might open some separate support issues later, but for now I'm happy that this has been resolved.

I was referring to SSL redirects, not all kinds of redirects, obviously, and no, you don't need to remove anything from Aegir, you have to do that for your site only, to avoid conflicts.