1

environment http://etrafficcontrol.com/misc/proxy.png

I have two applications. One is an e-commerce site (Drupal 7 running on LAMP) hosted on AWS, and the other is the checkout system which is ASP on IIS-6, is located inside our company, and requires SSL.

Currently we put up with the situation where our customers get forwarded to another domain for checkout -- kind of like what happens with ebay and PayPal. But this leads to difficulty with site tracking code, and kind of feels wrong for the shopper to get forwarded off of the e-commerce site for checkout.

The main concern is that we use Google campaigns, so we want to track conversions from advertising to, and rich content on, domain-1, but the actual sale happens at the time of checkout on domain-2.

Rather than send visitors from www.domain1.com/cart to domain2.com/miscX, I've tried to setup ProxyPass and ProxyPassReverse so I can send them to www.domain1.com/shop/miscX.

App1 (drupal) is in domain1.com/*, and the .htaccess stuff bypasses Drupal's design to intercept everything. The "misc" paths come from the fact that I'm redirecting into a subdirectory, and then proxying from there. When the proxied pages render, they have some hard-coded paths to /miscX, and without making special provisions for those during the rediects, I wind up with /miscX/ (instead of /shop/miscX/ which will follow the proxy) and that causes missing css, js, etc.

Note: Our business customers can login directly to domain2.com, so I'd like to keep that portal unchanged.

Below, local-d7 is a local test instance of the domain1 server. A test of the proxy shows that this concept works, with SSL.

I have this almost working, but it seems like URL-encoded parameters are being lost (even though query strings are ok). When I introduce the proxy, server2 doesn't appear see encoded params (it's a specialized app and I don't know how to view what IIS is receiving). When I route the domain2 test portal login thru apache on server-1 in such a way that doesn't have encoded params, the login works.

In effect I'm trying to

  1. reverse proxy
  2. change path (put an app running in / on domain-2 and expose into a subdir "/shop" on Domain-1
  3. support SSL
  4. proxy an IIS server behind Apache
  5. try to not modify the IIS server so that it can continue to be used by it's original domain-2.com URL, and
  6. do this on a hosted server where I [may] have limited configuration control of Apache. (currently testing on XAMPP).

I've tried all sorts of things in addition to what's shown here, including rewriterules, redirects, etc. I'm just not experienced at all at mod_proxy or mod_rewrite, etc. But it seems to me that this arrangement of a proxy should be doable with some amount of work and possibly fixing server SSL certificates.

Advice? --Thanks

vhosts.conf

  ## Redirect /misc1/ https://local-d7/shop/misc1/
  ## Redirect /misc2/ https://local-d7/shop/misc2/
  ## Redirect /misc3/ https://local-d7/shop/misc3/

  ## ProxyRequests Off
  ## ProxyPreserveHost On
  ## RequestHeader set Proxy-SSL true
  ## ProxyPass /shop/ https://www.shop.com/
  ## ProxyPassReverse /shop/ https://www.shop.com/

  ProxyPass /shop/ https://www.domain2.com/
  ProxyPassReverse /shop/ https://www.domain2.com/
  ProxyPass /misc1/ https://www.domain2.com/misc1/
  ProxyPassReverse /misc1/ https://www.domain2.com/misc1/
  ProxyPass /misc2/ https://www.domain2.com/misc2/
  ProxyPassReverse /misc2/ https://www.domain2.com/misc2/
  ProxyPass /misc3/ https://www.domain2.com/misc3/
  ProxyPassReverse /misc3/ https://www.domain2.com/misc3/

.htaccess

RewriteCond %{REQUEST_URI} ^/misc1/
RewriteCond %{REQUEST_URI} ^/misc2/
RewriteCond %{REQUEST_URI} ^/misc3/
RewriteRule (.*) /shop/$1
Mudd
  • 31
  • 6
  • It may "feel wrong" but if you go the ProxyPass route then any information that gets POSTed to the checkout pages will route through the Drupal server. If this includes credit card details you may fall foul of PCI-DSS. Keeping the checkout on domain2 may be the lesser evil (or create another vhost under domain1 on the company server) – Ian Roberts May 13 '14 at 20:18
  • Thanks for pointing that out. Due to SSL and URL encoding, I'm not convinced this is even possible, since the IIS server is running a certificate as "Domain-2" and the client would talking to Domain-1. – Mudd May 20 '14 at 13:35
  • Then you'll have to leave the user-facing URL of the checkout page as domain2, or assign a second IP address to your corporate server so it can serve something like `checkout.domain1.com` with its own certificate alongside the existing site for domain2. – Ian Roberts May 20 '14 at 13:52

0 Answers0