We will probably add a sample configuration for both nginx and apache to the website soon - once we do, we will not cover this particular case (using subdirectory structures), but rather using subdomains or domains for this, as it simplifies the configuration, is better for performance and probably also more favorable with regards to a system structure in general.
Thanks, Paul. I appreciate the help. I’m not seeing anything that looks really different from what I already tried for days without success. Like I said initially, I can use mod_proxy_html and I can set the force.host etc. to get a semi-working system, but it falls down in many places. There are internal gaps to be plugged. Perhaps the worse problem is that form submissions will get sent to the domain root, crash the page, and then if you press back and resubmit again - it sometimes magically works the second time! I believe that ajax complexities must involved there, which the apache mod doesn’t correct for.
I didn’t try the subdomain route you are suggesting. That’s not really what I want, but maybe a wise solution for now. I’d like see any configuration templates you could offer for that.
The differences to the config you sent us are:
- In your config static proxypasses are used, so if you miss any of the applications, it may not quite work
- The cookie domain isn’t set for the proxypass and proxypassreverse, so the session will be lost
- Anchor links will not be updated - we rely on ProxyHTMLURLMap, and there is nothing of that sort in the config you provided(again: this is only a workaround atm, but an important one)
- RequestHeader set X-Forwarded-Proto “https” early isn’t set, which may mean that scipio thinks it is being requested as “http”, even though you are running on https. There may be a problem with that, as it may kill sessions when you switch from insecure to secure urls with the system (this can be hidden from your result, as you are overriding the url with proxypassreverse).
That’s at least some of the issues we found, hopefully it may help you fix the issues.
And yes, using subdomains are much simpler here, as you can specify a simple VirtualHost with a proxy pass and then rely on our url.properties to properly create the urls. It should work much much better.
Let me know if this works for you
Yeah, I didn’t share all of the various configurations I tested. I only sent the one that worked reliably. I did, in fact, try essentially all of these suggestions.
I will give the VitualHost / subdomain a shot. That ought to at least prevent collisions with the domain root, so that would be an important improvement.
I’ll get back to you with my results in the near future. Thanks so much for all the assistance! These interactions greatly sets apart Scipio from OFBiz and most any of your competitors for that matter!
I should add: If your shop differs from the other apps and you want to run it on a seperate domain, you should update the WebSite entity for it and set the https domain there
You can do that through the ui: https://localhost/staff/scipio/catalog/control/EditWebSite?webSiteId=ScipioWebStore
Then you can add an additional virtualHost for your shop domain in apache. The configuration can be a simply proxypass and proxypassreverse to localhost:8080/shop in this case. Since you don’t have to deal with the subdirectories, that should work just fine.
It may be that you want to adjust the previous configuration from LocationMatch ^/staff/scipio/(.)$ to ^/staff/scipio/(?!shop)(.)$ for this though - just to make sure that shop isn’t also used on the other domain.
Lastly: You can run multiple Shops with multiple WebSite entities from within a single scipio erp server and by using the WebSite entities, you can use different domains for each…
I’m now much closer to having this straighten out, thanks to your help.
I setup a subdomain with an Apache virtual host. That worked very cleanly. The trouble with that, howvever, is I don’t have a wildcard ssl cert - so either I need to buy a another cert for the subdomain, or upgrade to that more expensive wildcard option. But, then I had the thought, well this doesn’t need to be publicly accessible, so instead a generated private client / server cross validating certs and made verification mandatory in that virtual host. So, now I have an ultra secure erp! This would not have been possible using the sub directory / context path plan.
Now, I’m stuck on getting the store to run properly on the root domain. I still want that to be accessed from https://mydomain.com/shop and use the natural public ssl cert.
I added a proxypass in the primary virtual host to just the /shop. That allows the store to be accessed, but it still falls apart because I’d need a proxy pass on the domain root / to point to the tomcat serlvet (or play other games the html mod, etc).
I figured the solution must be the whole “website entity” deal. But, I seem to be missing a fundamental point with that. Nothing I do appears to have any effect on the store. I defined one, and gave it a new title, and a catalog, and I played with alternate host settings, etc. but when I refresh my /shop page nothing ever changes. I’ve restarted Scipio, and cleared my browser cache, but no matter what it shows a (broken) store with content that doesn’t change and says at the bottom “A Product Store has not been defined for this shop.” even though I defined such. Clearly, I’m just not viewing the right store. What basic point did I miss?
Instead of buying a costly ssl cert, i recommend using https://letsencrypt.org/. It is free, easy to setup and renews itself every quarter. There is almost no downside to this, letsencrypt is sponsored by the industry leads who all have an interest in you securing your domain. It is good that you managed to set it up with a self-signed cert, but those do give others a very ugly warning message. Letsencrypt won’t do that to you…
The Website entry has to match the one defined by whatever is used from inside the shop component. ProductStore, Websites and the shop component are connected in the database. That is why i linked to https://localhost:8443/catalog/control/EditWebSite?webSiteId=ScipioWebStore - if you use the default store that link will point you to the right Website and changing it there should have an immediate effect. But if you are unsure about which one is being used, go to Catalog > Stores > Select your Store > Select "Web Sites from Menu > Select one of the ones that are being connected to the store or add a new entry.
In addition: You can actually also change the shop path to “/” by updating the ofbiz-component.xml inside of the application/shop component, too (or in case you override your shop with a custom one, from within that component instead). We sometimes do that on installations where we do not use entirely separate domains but still want to somehow run the store from / and the other applications from their subdirectories. We did that here as well: http://shop.scipioerp.com/. If you do that, though, I would recommend to also update your apache config so that the other apps are not accessible from the web (except for the themes, ordermgr and images). We most often move those configs to a seperate VirtualHost, which is only accessible when connected to via VPN (ie by using the internal IP). That way it is a bit more secure. Anyway, the WebSite entries are the better and more correct way, however…
That can also mean that the demo data or seed data is not correctly installed… but let’s assume you are just using a WebSite that is not connected to a ProductStore like I mentioned above for now…
Hmm. I’m not having a lot of luck. I had already defined a custom store. And had set that as “the store on the website”. I used the url you posted ending the query string with ScipioWebStore. That opened some parts that I couldn’t find a means to browse into with the menu system (there must be some navigation trick). Anyway, editing that had some effect on what I saw. It seems the database must be seeded in some manner that was binding it to that non-existence default store to begin with. I don’t see how to make my new store “the store”? Note that I’m running a “production” installation in this case, so there should not be a bunch of demo data.
The links etc. are still broken now that the default “ScipioWebStore” is being shown. I played with host settings in that site to no avail. It seems like the only way to get this to really work right is via another subdomain. There appears to be problems whenever one wants to “merge” together existing sites, rather than have scipio running on it own dedicated site. I don’t see how else this can be pulled off, behind a proxy because the store wants to resolve urls on the front end that simply don’t work without proxypasses into the domain root and direct offshoots like /images. I’d be forced to go back the long ugly list of proxypasses that create conflicts. Hence, why alternate context paths need to be supported.
As for the self-signed certs, I’m not just using a simple one-way cert. I have two way verification going on. A visitor is locked out unless they install a pkcs12 cert on the local end which is generated to authenticate them to the server, not just the other way around. That’s ultra secure. They can’t just “ignore” an ssl error. Having a error appear in the browser about being denied access is desirable for a backend app I want locked down.
Buying certs is generally better practice in my opinion, especially if you get EV certs. Depending upon the context, I deal with clients who will want to inspect the certificate to sure they are communicating across secure channels. It needs to be owned and controlled by the company directly - not a middleman.
In my immediate use case though, I might take that advise and use a freebie cert for this store and put it on a another subdomain. If I want, I can change that later. At least I should be able to see this part working as desired then, minus that detail.
Just as a quick one, as i am not at my desk atm: try renaming your storeid to ‘ScipioWebStore’ and retry. I’ll explain later
Will do. Thanks again!
Correction: it is the Website you have to change. So better change both
I’m going to go back play with getting my new store to be the one in use, but first I’m getting the apache part square.
So, I created another sub domain and virtual host for the shop. I’m just ignoring ssl errors for the moment until I slap a freebie on there. I set a proxy pass to the root of the virtual host so it points to the root of scipio servlet. That eliminates any context path problems.
On the store subdomain, I don’t want anything to be accessible other than the store (and it’s required resources). So, I started blocking certain urls within that virtual host. Here’s the critical parts of the virtual host:
<VirtualHost _default_:443> ... ServerName shop.mydomain.com SSLProxyEngine On ProxyRequests Off ProxyPreserveHost On ProxyPassReverseCookieDomain http://localhost:8180 https://shop.mydomain.com ProxyPass /accounting ! ProxyPass /admin ! ProxyPass /cms ! ProxyPass /commonext ! ProxyPass /content ! ProxyPass /humanres ! ProxyPass /manufacturing ! ProxyPass /marketing ! ProxyPass /order ! ProxyPass /party ! ProxyPass /product ! ProxyPass /securityext ! ProxyPass /setup ! ProxyPass /solr ! ProxyPass /workeffort ! ProxyPass / http://localhost:8180/ ProxyPassReverse / http://localhost:8180/ </VirtualHost>
On WebSite “ScipioWebStore”, I set the http host to https://shop.mydomain.com (note the crossing of http and https is purposeful, because the servlet runs on http, but it proxied by https) and I set the domain cookie to https://shop.mydomain.com.
Superficially, this all looks good. Are there other exclusions I should add? Or, conversely, will I have blocked anything that is required?
Actually, I realized that at the start of this, you posted a proxypass config for the store being at the root, and the specific dependencies for it also being proxied. I’ll try that approach… That’s exactly what I’d need in this virtual host.
it looks mostly good on a first glance. Just noticed you are not setting the Requestheader which you should do. There may be other things, but i say: give it a go and let us know how it works out
I tried the proxying the root to /shop (as shown in the initial example), but that doesn’t work. You just can’t mess any such context paths.
So I need this?
RequestHeader set X-Forwarded-Proto "https" early
It has not been needed in any of the standard erp apps, as I’ve messed with them.
Unfortunately, I don’t have any products defined, and I don’t yet know have to setup credit card processors (or ideally sandboxes for them for right now)… So “testing” the store in a comprehensive manner is a little ways off…
oh, but you can actually set shop to / but lets do that later.
As for the Header: it isn’t the most urgent thing, but it basically forwards the real ip to the system, which is important if you want scipio erp to also know which ip users are coming from (perhaps to block them or so). Other ERP systema have to do that too if they want to store the true user ids. Otherwise they will only get the one from their webserver
So everything works in principle now?