By a process of elimination, I'm pretty sure that teaCommerceCallBackUrl was being generated with just http (as the request is, by the time it reaches IIS).

I've worked around this by setting an IIS rewrite rule as follows;

            <rule name="Set HTTPS for HTTP_X_FORWARDED_PROTO https">
                <match url=".*" />
                <conditions>
                    <add input="{HTTP_X_FORWARDED_PROTO}" pattern="https" />
                </conditions>
                <serverVariables>
                    <set name="HTTPS" value="on" />
                    <set name="SERVER_PORT" value="443" />
                </serverVariables>
                <action type="None" />
            </rule>

(in our case, the Rackspace Cloud load balancer we use to terminate SSL sets the X-Forwarded-Proto header)

Note that to do this requires the server variables to be allowed to be set, which is a global IIS setting, in the applicationHost.config.

Coincidentally, this has also helped with all sorts of Umbraco url-generation issues, so I also no longer need to use baseUrl etc in the umbracoSettings.config to fix scheduledTasks or distributedCalls.

Hope this helps someone,

Phil

Hi Phil

Here is the code that generates the URL for Umbraco

https://github.com/TeaCommerce/Tea-Commerce-for-Umbraco/blob/master/Source/TeaCommerce.Umbraco.Configuration/PaymentProviders/PaymentProviderUriResolver.cs

Thanks Anders; that confirms that request.Url.Scheme is used, which would have caused this problem. The rewrite rules above work around that.

Phil

is working on a reply...