Hi
I have a site that is fully SSL enabled (no mixed modes enabled). But whenever I try to submit a form suddenly I see that the browser pad lock icon shows a warning that a non-secure communication is made. I have debugged the traffic using FIDDLER and saw that non-secure http requests are being triggered on clicking the submit button. (I have attached the FIDDLER images. Non secure requests are highlighted in Bold.) Please help.
Note 1:- Am using Google chrome browser. I have confirmed with fiddler that the non-secure http request is made during every form submission.
Note 2:- I am not using any extra modules to enable SSL in my site. I am using just APACHE mod_rewrite directives in my .htaccess file for enabling site wide SSL.
Best Regards
IT Admin
Comment | File | Size | Author |
---|---|---|---|
#9 | login form - ssl error.jpg | 160.51 KB | syam.mohan.vs |
#8 | Selection_2025.jpeg | 179.57 KB | greggles |
user-register.JPG | 125.68 KB | syam.mohan.vs | |
user-login.JPG | 79.96 KB | syam.mohan.vs | |
user-edit.JPG | 80.65 KB | syam.mohan.vs |
Comments
Comment #1
gregglesMarked #1850760: SSL Mixed Mode Warning during rule submission as a duplicate.
Comment #2
chx CreditAttribution: chx commentedComment #3
chx CreditAttribution: chx commentedYou need to set up a $base_url in settings.php if you mod_rewrite like this.
Comment #4
chx CreditAttribution: chx commentedWrong status.
Comment #5
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedThanks Guys. Is configuring $base_url the fix ? If my site is https://www.example.com then should i give $base_url = https://www.example.com ? Anyway I have tried that but that doesn't fix the issue. Please help.
Comment #6
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedChanging the status to "active".
Comment #7
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedchanging priority to critical.
Comment #8
greggles@it.admin - it should be sufficient to change the $base_url in the settings.php used by your site. I've just tested it and can confirm that works. If that isn't sufficient then there is something else at play on your site causing the problem. I suggest looking at the form method and actions on any pages where this is a problem. Is Drupal generating those forms? Do they have an action that is absolute or relative? Does the action contain http or https?
I setup webscarab to intercept my requests and could not repeat the results that you got (see attached).
Comment #9
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedThanks greggles. The problem seems to happen only with successful form submissions. You didn't see the error because you didn't log in successfully (same in my test - no error when no successful login). But with every successful login there is a non-https GET request going. I have tested this (see attached file) and the result is similar to the images I posted earlier.
I have created a test user for you to login and check. Details are given below.
Username - test
Password - test
Also the login form that you see is the standard drupal generated login form. And the error happens with successful submission of every drupal generated form.
Best Regards
IT Admin
Comment #10
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedChanging status to active.
Best Regards
IT Admin
Comment #11
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedchanging category to bug report.
IT Admin
Comment #12
gregglesI can confirm the behavior you describe on your site but on other sites I use that use https I do not see the same behavior.
My initial guess is that your site has a drupal_goto (in a contributed module, an action/trigger configuration, or a custom module) and that the drupal_goto isn't respecting the https (i.e. that it has http hard coded).
My second guess is that you modified the $base_url in the wrong settings.php file OR that the $base_url is being overwritten with the wrong value somewhere else after your settings.php.
Let's leave this as a support request until it's been shown to be a bug. Critical bugs in the core queue have a special meaning that blocks other progress and until we know for sure that this is a critical bug I don't think we should blog that progress.
Comment #13
syam.mohan.vs CreditAttribution: syam.mohan.vs commentedThanks greggles. Your second guess was right. I modified a different settings.php file. Now I have modified the correct settings.php file inside
sites/default folder. Now the problem is fixed. Thanks for the support.
Best Regards
IT Admin