I too was a little confused as to what your post had to to with the previous ones but I think I have some idea, maybe I can explain what we do which might help.
We have multiple web applications running on a live machine and a test machine, which has four environments - D, T, Q, REF (same as LIVE). Each web application is a Single Page Web App written using Angular, basically this means that the server just serves up the HTML but none of the content, which the apps retrieve via a web service. Each web application lives under its own root on the server. There is also a Tomcat based web-service, of which there is only one instance per environment because our web-service is generic, all it does is call stored procedures.
For example:
//ourserver/api
//ourserver/financial-dashboard
//ourserver/invoicing-app
//ourserver/some-other-great-app
These individual applications can quite happily be deployed on the same server without conflict (dealing with the dev machine and its different environments is a little trickier, I'll get to that later).
The "API" just delivers JSON data, so POSTing to "/api/cust_sp_query_by_name" will execute a stored procedure "cust_sp_query_by_name" and return a JSON structure containing a page of customer data. We use a token-based security method, whereby anyone wishing to call one of our restricted APIs must obtain a security token which is passed on each call to the API. In a web app, this is done by asking the user to login. I can explain more in detail how we solve that in another post if you like, but the key thing is that we validate the user against our Active Directory using the LDAP APIs, not against the IBM i itself, so our users don't require IBM i accounts. All the stored procedures that are restricted determine from this token if the user can execute them and what they should see.
To manage the multi-tier development environment is a bit more tricky, here's how we do it. We have four server instances running, one for each environment, and each on their own obscure port. We then use virtual hosting and reverse proxying on the IBM i HTTP server so that we can use a sub-domain for each environment:
//dev.our-dev-server/
//test.our-dev-server/
//qa.our-dev-server/
//ref.our-dev-server/
So all of these apparently live under port 80 of our test machine, but in reality, the reverse proxy simply examines the HTTP headers, looks a what host the request was intended for and forwards the request to the appropriate server instance at whatever port it's running on. For this to work you also need to ask your network support people to add the sub-domains or a wildcard *.our-dev-sever to point at your machine's IP address. Scary as this might sound, it's actually quite simple to set-up and if you got the reverse proxy up and running you're 90% there already.
If you really want to have your apps isolated from each other and running under their own server instance you can use the above technique, the apps can even have their own domain, as long as you add them or a wildcard to your DNS and point it at your IBM i. For example.
//alice.our-dev-server/
//bob.our-dev-server.local/
//chuck.our-dev-server.local/
For me this is unnecessary unless Alice, Bob and Chuck are developers and want their own playground in which to experiment, but just to keep individual production apps separate it's not worth it IMO and you'd potentially end up with dozens of server instances running.
The config for this would look something like this:
# Hack to prevent the server defaulting to the first subdomain when one is not provided.
<VirtualHost *:80>
ServerName dummy
AllowEncodedSlashes On
</VirtualHost>
# Repeat this for each subdomain.
<VirtualHost *:80>
ServerName alice.our-dev-server.local
ProxyPreserveHost On
ProxyPass /
http://localhost:18020/
ProxyPassReverse /
http://localhost:18020/
AllowEncodedSlashes On
</VirtualHost>
So Alice's server is running on port 18020. The "dummy" entry is because the server will default to the first sub-domain if the user doesn't provide one, which I didn't want, you could remove this entry if you don't mind this happening.
Tim.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Booth Martin <booth@xxxxxxxxxxxx>
Sent: 07 April 2019 08:42
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] CORS header 'Access-Control-Allow-Origin'
This is only the first part of my confusion. At the end of the quest I
want to provide Web Services as JSON data, consumable by staff inside
the VPN but who no need nor interest in having an i account and
password. They do, however need to have a place and way to consume that
data.
I see that as being web-delivered. Having everything jammed and
packed on to one server strikes me as inviting needless conflict and
frustration. Its pretty clear that not everyone gets port 80 for
"their" baby. Therefore, to field an end to end solution I am going to
have to understand how to make it all work on the i.
Is this issue really about the Internet and not i-related at all?
Maybe. But I am thinking there is more to it. I've had my own web site
for 20+ years and generally work through these issues fairly easily.
On 4/6/2019 9:56 PM, Scott Klement wrote:
Booth,
You say you want labs/alice, labs/bob and labs/chuck to point to home
pages. Great!
What does this have to do with ACAO, Web Services and reverse
proxies? I don't understand the connection.
-SK
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Cd056b75b3a1943a13bcb08d6bb243a0b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636902161593059963&sdata=%2Bq%2Br0iEaUERparJaOcOPlCSbfIbRAsqF3TWzlTTmEvo%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Cd056b75b3a1943a13bcb08d6bb243a0b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636902161593059963&sdata=OnD0tlvQTMucHXpsxL8fKNjbcC8CNVmJHBNowT7L%2BTQ%3D&reserved=0.
midrange.com
