VBullentin with Vaultwiki behind SSL proxy does not save changes

Hi

I think we fixed this in the past but the 3.0.11 patch has reverted the change.

The problem is when you try to save a page edit it doesnt save.
Probilem description:

Wiki is not saving edits - when you press sav you get: Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.
Are you sure you want to continue sending this information?

Pegasus, do you remember what we did to fix this the last time ?
I think it was changing some POST url to not differentiate between http and https or something.

You're encountering this here? Or your site? I thought I have made edits here since adding SSL...

The fix we used last time has been included in VaultWiki since then. Looking at the 3.0.11 source code, I see the fix applied in the appropriate spots. If you are still having issues, either the changes never had any effect, you copied over your fixed files with older files by mistake, or there has been some change to the proxy server you didn't notice before...

Also, if you downloaded a patch rather than the full update, make sure you downloaded the right one. If you selected a changed-since version that is later than your previous install, you would have missed some changed files.

If you cannot resolve this on your own, send me a PM.

Found your problem. In order for VaultWiki to match the current URL protocol being used, it needs to be able to detect the current protocol. When HTTPS is being used, the PHP environment variable $_SERVER['HTTPS'] should be set to on or 1, but it isn't set in your configuration. This is something that you would set in your proxy configuration. Once you set this appropriately, you should no longer have issues.

Keep in mind that VaultWiki doesn't force any redirect if the wrong protocol is used; it's agnostic. Whenever http is being used, your server is forcing a redirect. I feel like you shouldn't a redirect on POST requests to avoid data loss from form submissions.

Yup, I agree this is the cause.

The problem is I'm running a load balancer and an SSL accelerator infront of load balancer.
Problem is backend wont see SSL at all, that is all handled by the SSL accelerator.

Is there a way to force it to sent over https anyway?

What are you using to achieve this? Can you be more specific about what code / server config is being used? Depending on your setup, you may be able to set the aforementioned PHP environment variable if the server can detect the request was passed through the proxy.

Or if it is ALWAYS sent through the proxy (your site doesn't use regular HTTP at all), add the following to your vBulletin config file (includes/config.php) anywhere after the copyright block:

Code:

---

$_SERVER['HTTPS'] = 1;

---

I think you can also set this as a default value either in php.ini or your http server config. In NginX we tell it to set HTTPS when the server proxies to PHP, technically this is possible even if the original request wasn't.

Otherwise you're going to have to get creative and perhaps have the proxy set a custom header before passing the request on. Once PHP gets the request, you can set the variable if the header is present.

I'm using varnish and "pound" infront of Varnish as the SSL accelerator.
Varnish by itself doesnt do SSL but pound is used to solve this problem.

I shall try this setting in config.php.

Didnt seem like $_SERVER['HTTPS'] = 1; after the vbulletin copyright part helped.


The proxy can set a special header.
But isnt it better if vbform uses the relative path instead of full address?

<form name="vbform" action="/forums/showwiki.php?title=Huginn&amp;do=edit" method="post" onsubmit="return

instead of

<form name="vbform" action="http://www.domain.com/forums/showwiki.php?title=Huginn&amp;do=edit" method="post" onsubmit="return

Then it'll submit using whichever the browser is using.
The search field and all other submit fields uses the relative path.

If PHP is running as a CGI or FastCGI, you should also be able to set $_SERVER['HTTPS'] when the server passes a request to PHP. For example, in NginX's nginx.conf, we use:

Code:

---

                        fastcgi_param HTTPS on;

---

Otherwise, it looks like I was mistaken and that includes/config.php is 1 line too late in the code. If you are unable to set it when calling PHP, you'll have it add it to the beginning of includes/class_core.php and remember to put it there after every vBulletin upgrade.

We don't use relative URLs because VaultWiki allows you to put your wiki on a custom sub-domain or non-forum path.

Thanks, this seems to have fixed it :)
I think the $_SERVER['HTTPS'] = 1; in class_core.php is the easiest and most portable solution for now.

Added a new setting in VaultWiki 4 Alpha 1 that allows you to choose how the protocol for wiki URLs in enforced.

Options are:

• Auto-detect (recommended)
• http://
• https://

In your case, you would want to select the 3rd option since auto-detect doesn't always work behind a proxy.