View Issue Details

IDProjectCategoryView StatusLast Update
0005855OXID eShop (all versions)4.08. Cachepublic2024-01-17 08:21
Reportermark Assigned To 
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionwon't fix 
Product Version4.8.7 / 5.1.7 
Fixed in Version6.0.0 
Summary0005855: oxConfig::getWidgetUrl can produce SSL Urls
Descriptionsmarty plugin function.oxid_include_widget.php uses oxConfig::getWidgetUrl to generate esi url. this should not be ssl if varnish is active because varnish then build urls urls like

ObjHeader c x-url: /https://SHOPDOMAIN/widget.php?actcontrol=start&cl=oxwservicemenu&nocookie=1&noscript=1&oxwparent=start

ObjHeader c Location: http://SHOPDOMAIN/https://SHOPDOMAIN/widget.php/?actCampaign=0&actClass=start&cl=ecs_tracking_trackingoutput&mControllerValue=&nocookie=1&noscript=1

In normal setup https is not active behind ssl terminator

Firewall/SSL Termination -> varnish -> Appserver

So if you use absolute urls, traffic is routed back if domain or protocol is different to the wrapping request (page which includes widget).

This commit added SSL-Support to widget urls:
https://github.com/OXID-eSales/oxideshop_ce/commit/392661c8502f2bd4c031a726175acc9c4a502470
https://bugs.oxid-esales.com/view.php?id=5790

Our setup stopped working with this lines, so please add something like "if rpcachebackend->active" to avoid ssl urls if varnish is active (ssl is useless then).
Steps To Reproducehard :-)
TagsHTTPS, Varnish
ThemeAll
BrowserAll
PHP VersionNot defined
Database VersionNot defined

Activities

mantas.vaitkunas

2014-08-20 10:58

reporter   ~0010078

Last edited: 2014-08-20 12:24

Hi,
to form SSL url is decided by function oxConfig::_checkSsl(). This function should always return false if varnish is in between client and frontend server. It might be that this function returns wrong result because of HTTP_X_FORWARDED_SERVER header.
Could you try to change this header value or do similar changes in oxConfig::_checkSsl() function to check if problem disappears?

mark

2014-08-20 11:44

reporter   ~0010079

21 RxHeader c X-Forwarded-Proto: https
   21 RxHeader c X-Forwarded-Protocol: https
   21 RxHeader c X-Forwarded-Server: ssl

This intends the checkSsl to be true und the getWidgetUrl to return https:// which causes the problem.

Sample:
 - My browser sends the request for https://somedomain/checkout/basket
 - Firewall decrypts ssl, adds header (X-Forwarded-Server: ssl) and forwards http://somedomain/checkout/basket
 - varnish takes request and fetches from Appserver (using http)
 - Appserver responds <html><body><esi:include src='https://somedomain/widget.php?'></body></html>
 - varnish recognizes, that document on http://somedomain is not the same as include on https://somedomain and requests the esi resource by this:

http://somedomain/checkout/basket/https://somedomain/widget.php?

right?

mantas.vaitkunas

2014-08-20 12:49

reporter   ~0010080

Yes

jurate.baseviciene

2014-11-24 14:52

reporter   ~0010347

Hi,

We changed priority of this bug to lower, because we provided fix how need to fix this problem by themself.

Best regards,
Jurate

Sven Brunk

2024-01-17 08:21

administrator   ~0016120

In more recent versions, this has been moved to a module. If changes are needed, you can override this in your own module.
On the other hand, I would not really consider this a bug in the shop framework. You tell the shop that it should either speak HTTP oder HTTPS. Which it does.
The rest of your setup needs to be configured accordingly. If Varnish does not handle the URLs correctly, you will have to configure it, so it does.