Ah. I see. Yeah, I would want the headers forwarded to the store I suppose for traffic analysis. That makes sense.
It’s not actually possible to make the store the root of the VirtualHost it seems. Else, I’m missing a detail trying to make that work. If you proxy “/” to “/store” than something like “/images” would become “/store/images”. Now I put those specifics first in the proxy order to avoid that, but still things are falling down. I guess I’m missing exceptions to that “which is root” rule.
Essentially, this still looks messed up:
ProxyPass /images/ http://localhost:8180/images/ ProxyPass /base-theme/ http://localhost:8180/base-theme/ ProxyPass /foundation-shop-theme/ http://localhost:8180/foundation-shop-theme/ ProxyPass /ordermgr-js/ http://localhost:8180/ordermgr-js/ ProxyPassReverse /images/ http://localhost:8180/images/ ProxyPassReverse /base-theme/ http://localhost:8180/base-theme/ ProxyPassReverse /foundation-shop-theme/ http://localhost:8180/foundation-shop-theme/ ProxyPassReverse /ordermgr-js/ http://localhost:8180/ordermgr-js/ ProxyPass / http://localhost:8180/shop/ ProxyPassReverse / http://localhost:8180/shop/
For instance, when you click “Log In” (which is displayed in a messed up manner), you get the error:
The requested URL /shop/shop/control/checkLogin/main was not found on this server.
Hold up. I may have it. I added a proxypass for /shop, and I went back to that big pile I posted previously. Now it looks right! (working right? idk… hopefully!)
ProxyPass /images/ http://localhost:8180/images/ ProxyPass /resources/ http://localhost:8180/resources/ ProxyPass /ordermgr-js/ http://localhost:8180/ordermgr-js/ ProxyPass /base-theme/ http://localhost:8180/base-theme/ ProxyPass /bootstrap-theme/ http://localhost:8180/bootstrap-theme/ ProxyPass /foundation-shop-theme/ http://localhost:8180/foundation-shop-theme/ ProxyPass /foundation6-theme/ http://localhost:8180/foundation6-theme/ ProxyPass /ignite-admin-theme/ http://localhost:8180/ignite-admin-theme/ ProxyPass /ignite-shop-theme/ http://localhost:8180/ignite-shop-theme/ ProxyPass /metro-theme/ http://localhost:8180/metro-theme/ ProxyPassReverse /images/ http://localhost:8180/images/ ProxyPassReverse /resources/ http://localhost:8180/resources/ ProxyPassReverse /ordermgr-js/ http://localhost:8180/ordermgr-js/ ProxyPassReverse /base-theme/ http://localhost:8180/base-theme/ ProxyPassReverse /bootstrap-theme/ http://localhost:8180/bootstrap-theme/ ProxyPassReverse /foundation-shop-theme/ http://localhost:8180/foundation-shop-theme/ ProxyPassReverse /foundation6-theme/ http://localhost:8180/foundation6-theme/ ProxyPassReverse /ignite-admin-theme/ http://localhost:8180/ignite-admin-theme/ ProxyPassReverse /ignite-shop-theme/ http://localhost:8180/ignite-shop-theme/ ProxyPassReverse /metro-theme/ http://localhost:8180/metro-theme/ ProxyPass /shop/ http://localhost:8180/shop/ ProxyPassReverse /shop/ http://localhost:8180/shop/ ProxyPass / http://localhost:8180/shop/ ProxyPassReverse / http://localhost:8180/shop/
Just an update: In the recent Git master branch we have made changes so it is possible to set a “webapp path prefix” in Scipio so that the generated links contain a path prefix, before the regular context path (that you must then make your load balancer rules match up with of course).
You can set a global prefix for all apps in
It is then possible to make an exception for Shop by setting the “Webapp Path Prefix” field to a single slash
/ (or other path) on this screen:
Please note this feature and several major link-building improvements are still under testing, so if you try this, please report any problems, thank you.
Fantastic! Thanks, guys. I’ll give this a try in the near future for sure.
Has anyone resolve this issue? because currently this is also my problem
Hey there marksman,
and welcome to the community.
Yes, this has been addressed and we wrote down a better configuration example afterwards: https://www.scipioerp.com/community/developer/installation-configuration/clustering/webserver-configuration/
After many days of banging my head against the wall, I ended up using the subdomain design instead, per the original way they planned for this to work. It functioned more reliably (and faster) for me than anything else I attempted. Once I did that, I also created private SSL certs for the subdomain that are bi-bidirectionally validated. With that in place, the system is ultra secure. Instead of just a password, the user can’t access anything without the private certs. As such, I decided that was ultimately better anyway, despite being more work to setup and maintain.
Now, that private cert idea doesn’t work for the shop, of course, which must be open to the public, so on that subdomain I used an alternate cert. I went with a free one, so as to not to not run up an extra bill. Had I planned this ahead of time, I would have used a free one on my domain root, and a fancy paid one for the shop. Or, if I weren’t so cheap, I’d have just bought a wildcard cert (which works across subdomains). That’ s the easiest solution if you want to go with the subdomain plan while avoiding the hassle of having numerous certs and configurations for them.