[SOLVED] SSL Redirect within admin

[milehigh]

Saturday morning, spot checked a couple sites and they were all unstyled and ignoring the CSS and JS.

Cleared cache manually...and same thing still all unstyled. View page source revealed that base href has HTTPS:// and the links to my CSS and js files were also switched to HTTPS. Since the site has no certificate the browser didn't load it leading to the unstyled version of the page (unless you manually override the invalid certificate warning).

Logged into the admin and noticed that none of the links worked to expand or contract the menus (because the JS files were indicating SSL) and even though I can get it and edit a page, any actions submit or cancel actions redirected me to an SSL page.

I jumped into config.php and set:
$config['ssl_url'] = 'http://www....';<-- NOTE HTTP:
$config['root_url'] = 'http://www....';
$config['admin_url'] = 'http://www..../admin;

Reloaded sites...and now they looked normal, but I had to indicate http: in my config ssl_url setting. (Not HTTPS)

Admin works a little better...but I still get the HTTPS:// form action when trying to save or edit a page.

Has anybody ever seen this behaviour? This is all of a sudden, with one particular host, across about 15 websites. I've tried 5.3, 5.3 FCGI and 5.5/ I've been on this host for 2 years with no issues.

Here is a representative php info:
http://s151971.gridserver.com/gs-bin/phpinfo.php-stable

I see the problem on versions 1.9, 1.10 and 1.11 and I even tried 2.0 beta 2 so CMSMS version isn't the issue.

The hosts claims they've changed nothing on their end...but I know I've changed nothing on mine.

Would love to see if anybody has any feedback here...my next step is switching hosts but that's a pain and I reallly don't want to. My CMSMS installs on other hosts continue to operate perfectly.

Code: Select all

----------------------------------------------
Cms Version: 2.0-beta2
Installed Modules:
AdminSearch: 1.0
CMSContentManager: 1.0
CMSPrinting: 1.50
DesignManager: 1.0
FileManager: 1.5
MicroTiny: 2.0
ModuleManager: 2.0
Navigator: 1.0
News: 2.50
Search: 1.50

Config Information:
php_memory_limit:
max_upload_size: 20000000
url_rewriting: none
page_extension:
query_var: page
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true
timezone: America/Chicago

Php Information:
phpversion: 5.5.17
md5_function: On (True)
json_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference:
test_db_timedifference:
memory_limit: 128M
max_execution_time: 300
output_buffering: 0
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 20M
upload_max_filesize: 20M
session_save_path: No check because open basedir active
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:
Server Api: cgi-fcgi
Server Db Type: MySQL (mysqli)
Server Db Version: 5.1.61
Server Db Grants: Could not find a suitable "GRANT ALL" permission, this does not necessarily lead to problems... But if you have problems installing/removing modules or adding and deleting items/pages this could be the cause!
Server Time Diff: No file system time difference found

----------------------------------------------

[calguy1000]

i will bet money that if you did this in a dummy page somewhere:

Code: Select all

{debug_display($smarty.server)}

and then browsed to that page. you would see that HTTPS is 'on' (or at least set, and not 'off') even for HTTP requests.

That would indicate a server issue... at least a recent server change.

Just for curiosity purposes... is the effected server with MediaTemple?

[calguy1000]

CMSMS behavior does not change by itself over the course of multiple days. Once you have setup the system, somebody has to do something for the behaviour to change.

So if your system 'all of a sudden' broke.... and nobody has done anything in the admin console/ftp accounts/etc...

Then look for either server changes or malware.

Edit: well of course available resources (disk space/memory, throughput) could change over time, or load could increase overtime causing a pull on resources... but that's not what is causing this issue.

[milehigh]

i will bet money that if you did this in a dummy page somewhere:

Code: Select all

{debug_display($smarty.server}

and then browsed to that page. you would see that HTTPS is 'on' (or at least set, and not 'off') even for HTTP requests.

That would indicate a server issue... at least a recent server change.

Just for curiosity purposes... is the effected server with MediaTemple?

It is MediaTemple. Been through several chats and phone calls and they first claim that there was a related issue affecting other clients and then it was solved yet I'm still seeing it 3 days later. If I code everything in my config.php I can get the site usable but I've never had to do that before.

If I pick up an installation as is on Mediatemple and move to a VPS, without changing a thing (other than the path of course) everything works fine.

It's been a good solution so far for low traffic types of websites so I'm hoping they get it resolved.

I am certain this is not a CMSMS issue but I think the host is playing the 'it's not me' game as well unfortunately.

$smarty.server outputs HTTPS but with no value.

[WM_UCONTROL_XMLRPC_SERVER] => http://10.0.0.13
[HTTPS] =>
[ACCESS_DOMAIN] => s151971.gridserver.com

[calguy1000]

There is some inconsistency in how various parts of the core detect if the request is an HTTPS request or not. This could cause your form actions to be prefixed with https: where other URLS are not.

However, since this behaviour has popped up on you within the last few days I'd say tell the MediaTemple guys to un-do what they have done.

[paulbaker]

Note this related post:
http://forum.cmsmadesimple.org/viewtopi ... 28&t=71526
You are both having the same recent trouble at MediaTemple. You can't both be wrong! Maybe tackle them together?

[calguy1000]

try something like this in your config.php

Code: Select all

if( array_key_exists('https',$_SERVER) && $_SERVER['https'] == '') {
   unset($_SERVER['https']);
}

[milehigh]

No luck with that either...I've tried a few iterations within my htaccess as well such as this:

Code: Select all

RewriteCond %{ENV:HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

but nothing works 100% the way it should or always has in the past.