I am still having the same problem as the post here http://drupal.org/node/215876
I created a seperate issue because that problem was with apache and I am running the nginx server and it may be a different problem. I am running:
-Drupal 6.8
-Secure Pages 6.x-1.7-beta2
-Nginx +fastcgi
-PHP version 5.2.6-2ubuntu4
-Ubuntu Intrepid 8.10 server
when viewing my phpinfo there is no _SERVER['HTTPS'] variable, but in the "SSL" section it does say ssl is enabled. I can view https://example.com/admin/settings/securepages with no problem, but the radio button is greyed out and unselectable. I have not tried the dev version as it is an earlier build of the module.
Comments
Comment #1
gordon commentedCan you add the $_SERVER section of the phpinfo(). This will enable me to add support for this.
Comment #2
luckysmack commentedthere is a $_SERVER section in the phpinfo(), just no _SERVER['HTTPS'] variable. here are the list of server variables at the end of the phpinfo() list:
PHP Variables
Variable Value
_REQUEST["pma_lang"]
_REQUEST["pma_charset"]
_REQUEST[""]
_REQUEST[""]
_REQUEST["pma_fontsize"]
_REQUEST["has_js"]
_REQUEST["phpMyAdmin"]
_REQUEST["dhtml_menu"]
_SERVER["SUDO_GID"]
_SERVER["USER"]
_SERVER["MAIL"]
_SERVER["HOME"]
_SERVER["PS1"]
_SERVER["SUDO_UID"]
_SERVER["LOGNAME"]
_SERVER["USERNAME"]
_SERVER["TERM"]
_SERVER["PHP_FCGI_MAX_REQUESTS"]
_SERVER["PATH"]
_SERVER["LS_COLORS"]
_SERVER["SUDO_COMMAND"]
_SERVER["SHELL"]
_SERVER["SUDO_USER"]
_SERVER["PHP_FCGI_CHILDREN"]
_SERVER["PWD"]
_SERVER["FCGI_ROLE"]
_SERVER["SCRIPT_FILENAME"]
_SERVER["QUERY_STRING"]
_SERVER["REQUEST_METHOD"]
_SERVER["CONTENT_TYPE"]
_SERVER["CONTENT_LENGTH"]
_SERVER["REQUEST_URI"]
_SERVER["DOCUMENT_URI"]
_SERVER["DOCUMENT_x"]
_SERVER["SERVER_PROTOCOL"]
_SERVER["GATEWAY_INTERFACE"]
_SERVER["SERVER_SOFTWARE"]
_SERVER["REMOTE_ADDR"]
_SERVER["REMOTE_PORT"]
_SERVER["SERVER_ADDR"]
_SERVER["SERVER_PORT"]
_SERVER["SERVER_NAME"]
_SERVER["REDIRECT_STATUS"]
_SERVER["HTTP_HOST"]
_SERVER["HTTP_USER_AGENT"]
_SERVER["HTTP_ACCEPT"]
_SERVER["HTTP_ACCEPT_LANGUAGE"]
_SERVER["HTTP_ACCEPT_ENCODING"]
_SERVER["HTTP_ACCEPT_CHARSET"]
_SERVER["HTTP_KEEP_ALIVE"]
_SERVER["HTTP_CONNECTION"]
_SERVER["HTTP_COOKIE"]
_SERVER["PHP_SELF"]
_SERVER["REQUEST_TIME"]
_SERVER["argv"]
Array
(
)
_SERVER["argc"]
_ENV["SUDO_GID"]
_ENV["USER"]
_ENV["MAIL"]
_ENV["HOME"]
_ENV["PS1"]
_ENV["SUDO_UID"]
_ENV["LOGNAME"]
_ENV["USERNAME"]
_ENV["TERM"]
_ENV["PHP_FCGI_MAX_REQUESTS"]
_ENV["PATH"]
_ENV["LS_COLORS"]
_ENV["SUDO_COMMAND"]
_ENV["SHELL"]
_ENV["SUDO_USER"]
_ENV["PHP_FCGI_CHILDREN"]
_ENV["PWD"]
_ENV["FCGI_ROLE"]
_ENV["SCRIPT_FILENAME"]
_ENV["QUERY_STRING"]
_ENV["REQUEST_METHOD"]
_ENV["CONTENT_TYPE"]
_ENV["CONTENT_LENGTH"]
_ENV["REQUEST_URI"]
_ENV["DOCUMENT_URI"]
_ENV["DOCUMENT_x"]
_ENV["SERVER_PROTOCOL"]
_ENV["GATEWAY_INTERFACE"]
_ENV["SERVER_SOFTWARE"]
_ENV["REMOTE_ADDR"]
_ENV["REMOTE_PORT"]
_ENV["SERVER_ADDR"]
_ENV["SERVER_PORT"]
_ENV["SERVER_NAME"]
_ENV["REDIRECT_STATUS"]
_ENV["HTTP_HOST"]
_ENV["HTTP_USER_AGENT"]
_ENV["HTTP_ACCEPT"]
_ENV["HTTP_ACCEPT_LANGUAGE"]
_ENV["HTTP_ACCEPT_ENCODING"]
_ENV["HTTP_ACCEPT_CHARSET"]
_ENV["HTTP_KEEP_ALIVE"]
_ENV["HTTP_CONNECTION"]
_ENV["HTTP_COOKIE"]
Comment #3
gordon commentedWhat I need to know is the $_SERVER ver which indicates that the request in in SSL and what the contents of this var is so that I can compare to determine that it is secure.
Gordon
Comment #4
simeHi bigmack83, you'll need to configure your nginx vhost as per this post.
http://blog.skateinmars.net/post/2007/11/01/phpMyAdmin-and-HTTPS-on-nginx
Comment #5
gordon commentedI look through and pulled out the bit that you want.
Comment #6
luckysmack commentedAwesome, Ill try that in a few minutes and report back if i can get it to work. Thanks
EDIT: Ok, the radio button is now available and going to an https address goes through, but all links that are not admin pages, or pages that according to the list shouldn't be in https are in https. It seems that for whatever reason drupal isnt able to tell when not to use a non secure page. So if enabled all my pages are secured through ssh. I can manually add or remove the 's' and works fine, but the links don't resolve properly. the following settings on the securepages settings page are what mine are set to:
Enabled
[x] Switch back to http pages when there are no matches
Non-secure Base URL:
-http://domain.com
Secure Base URL:
-https://domain.com
Pages which will be be secure:
-[]Make secure every page except the listed pages.
-[x]Make secure only the listed pages.
--node/add*
--node/*/edit
--user/*
--admin*
Ignore pages:
-*/autocomplete/*
-*/ajax/*
This is an example of my vhost:
(*Note, i have the "fastcgi_param HTTPS on;" in both sections, though i have tried it only in the *:443 section but had the same results)
Comment #7
seanberto commentedI'm encountering the same issue. I believe that I have nginx configured correctly for SSL. W/o the securepages module enabled, I can visit my site with either SSL or non-SSL connection. However, if I go to admin/build/securepages w/o an HTTPS connection and enable the module, it correctly switches to HTTPS. If I then stay on admin* pages, my HTTPS connection persists. If I go to /home, my connection correctly goes back to HTTP. However, if I then go back to an admin* page, I am not redirected to HTTPS.
Just for grins, I installed the securepages_hijack_prevention module. With this module enabled, if it appears that HTTP and HTTPS connections are switched back and forth correctly. However, everytime I go from a non-HTTPS connection to an HTTPS connection, I'm logged out.
Is it possible that this has something to do with how nginx handles sessions?
-sean
Comment #8
mshaver commentedWe are having similar trouble getting secure pages working with nginx for a vhost. This is also a Drupal multi-site setup, although that should really matter I don' think.
One thing that is happening to our URLs that hasn't been mentioned is that they will get a double hash after the base URL when redirected to the ssl version of the page. So it will be something like this: https://domain.com//user/login
Comment #9
luckysmack commentedthe double slashes are likely because of the rewrite rules in the vhost files. try taking out the last "/" in the rewrite url and see if that fixes it
Comment #10
mshaver commentedYes, this turned out to be the try_files method in nginx of rewriting the url. It's working now that we aren't using this method. Now it looks like it's not switching back and forth between https and http though?
Comment #11
j0rd commentedfastcgi_param HTTPS on resolves my issue. Posting for prosperity.
Comment #12
pianory commentedThis is an old thread, but perhaps this will help someone:
There is a default /etc/nginx/fastcgi.conf file. In that file, I added this line:
fastcgi_param HTTPS $https;
Then in my server {} configuration, I did this:
server {
server_name domain.net;
set $https off;
include /etc/nginx/fastcgi.conf;
...
}
server {
listen 443 ssl;
server_name domain.net;
set $https on;
include /etc/nginx/fastcgi.conf;
...
}
I also made sure to remove inclusion of /etc/nginx/fastcgi.conf in other files, such as nginx.conf, so that it would only be loaded in the server { } areas I had designated.
Hope this helps someone! I had tried several other methods to no avail, and the code comment #6 by luckysmack sets HTTPS to "on" when on port 80, which is wrong. It should be set to "off" (or not set) when using port 80.
Ryan
Comment #13
gordon commentedIf you can upload a copy of your phpinfo() which is run while your browser is running from https then we can see why it is not being detected.
Comment #14
kevinquillen commentedI had an issue where the switchback wasn't happening, and I am running nginx as well.
Here is what I had to change to get it to work more reliably:
In my Drupal settings.php:
Taking a cue from: http://framework.zend.com/issues/browse/ZF-5012
Comment #15
kevinquillen commentedComment #16
kevinquillen commentedBoost 6.x-1.18 with Nginx also seems to interrupt the switching process. Disabling Boost helps, too, but not really ideal for some sites.
Comment #17
grendzy commentedBetter docs is on my wishlist, and in the meantime please check out http://www.metaltoad.com/blog/running-drupal-secure-pages-behind-proxy which has instructions for setting up your proxy to work with securepages.
Comment #18
kevinquillen commentedYeah, we have the settings.php method. Boost still fails though, everything else works.
Comment #19
kevinquillen commentedQuick update here, ran into this same exact problem on another site.
If you have the option 'Make secure only the listing pages' set, if you have paths listed in the Ignore box (like node/add* and node/*/edit) they do not redirect. When I removed the node/add* and node/*/edit from being Ignored by SecurePages, the switchback worked as expected.