Can someone confirm the code that determines the teaCommerceCallBackUrl, when passed into GenerateHtmlForm in a payment provider?
I have an issue in production, that I can't replicate when debugging locally - I suspect it might be that the url being generated is http, because I'm using SSL termination on an external load-balancer, so as far as Umbraco is concerned, the request is http (similar problems exist with scheduledTasks and load balancing within Umbraco itself).
If teaCommerceCallBackUrl is generated using the Request.Scheme, that'll be my issue...
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;
(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.
https teaCommerceCallBackUrl
Can someone confirm the code that determines the teaCommerceCallBackUrl, when passed into GenerateHtmlForm in a payment provider?
I have an issue in production, that I can't replicate when debugging locally - I suspect it might be that the url being generated is http, because I'm using SSL termination on an external load-balancer, so as far as Umbraco is concerned, the request is http (similar problems exist with scheduledTasks and load balancing within Umbraco itself).
If teaCommerceCallBackUrl is generated using the Request.Scheme, that'll be my issue...
Phil
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;
(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...