"For those who favor an XMLSERVICE interface over an API interface, I'm
curious how you handle end-user access privileges? XMLSERVICE, ODBC, JDBC,
and the like allow clients to execute any SQL statement against any
database files, to call any program, to run any command. What is your
preferred way of controlling that?"
As I mentioned elsewhere, we don't allow any old SQL statements to run, just stored procedures, these are compiled with USRPRF(*OWNER) and the JDBC connection user profile just has use rights to the stored procedures with no rights at all to the files, so that's the first way in which we limit what the caller can do. For individual user access control we pass an authentication token from the HTTP header to the stored procedure via the SET_CLIENT_INFO() function which the called stored procedure decrypts and tests the validity of, as well as figuring out the ID of the caller and whether they are authorised to the stored procedure and the data it accesses. If the token is missing, invalid or expired then the stored procedure sends an exception which is interpreted by our framework and sent back to the client as a 401 - Not authenticated status. The client then redirects to a login page and the user enters their credentials which are posted to the server. This is again just a simple stored procedure call which validates the credentials and then sends back a token, which the client stores and adds to every subsequent HTTP request in the header.
I don't want to ramble on too much, but I can give you some concrete examples if you like and the source is all on BitBucket anyway.
________________________________
From: WEB400 <web400-bounces@xxxxxxxxxxxx> on behalf of Nathan Andelin <nandelin@xxxxxxxxx>
Sent: 23 March 2018 17:04
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] REST web service APIs
Nadir,
Thanks for your response. I followed the link that you provided and further
linked to the following:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fcloud%2Fintegration&data=02%7C01%7C%7Cb538754bc53145dd794408d590d7e098%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636574179209041864&sdata=399oqkrfPLLaLjiF%2BFAeZb9bztx8ykov0xiZHDHjnoU%3D&reserved=0
Halfway down that page there is a link to a 3 minute video with the
following text:
"Learn how Walmart is building a platform driven by APIs to provide its
developers with a self-service portal that supports faster development and
helps Walmart deliver new services and improvements at the speed of
business."
The technicians at Walmart briefly discuss the benefits of their API
architecture. That intrigued me because we've had some shallow comments on
this list this past week about Walmart using Node.js for a high-volume
shopping site. That video suggest that there is a lot more to the story
than just switching to Node.js.
For those who favor an XMLSERVICE interface over an API interface, I'm
curious how you handle end-user access privileges? XMLSERVICE, ODBC, JDBC,
and the like allow clients to execute any SQL statement against any
database files, to call any program, to run any command. What is your
preferred way of controlling that?
With APIs, I envision a service that checks a list to see if users have
been granted authority to an API, and providing an appropriate error
message if otherwise.
Nathan.
On Fri, Mar 23, 2018 at 8:35 AM, Nadir Amra <amra@xxxxxxxxxx> wrote:
Hi, it is a viable alternative. There are multiple ways to do this and
you may choose the best one that suits your needs. I will also point out
that integrated web services server[1] documents it services via Swagger.
[1] https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Disg3T1026868&data=02%7C01%7C%7Cb538754bc53145dd794408d590d7e098%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636574179209041864&sdata=HJsR37r4QpmpgEPF%2FAqOaZSnZ1mjurfm3%2FsvyfMmcUY%3D&reserved=0
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fweb400&data=02%7C01%7C%7Cb538754bc53145dd794408d590d7e098%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636574179209041864&sdata=nez6PSeAGMlaJAPiFalpGBQUP9LWFfZQkzadJTIgFaU%3D&reserved=0
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fweb400&data=02%7C01%7C%7Cb538754bc53145dd794408d590d7e098%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636574179209041864&sdata=VFMezBhj8mzvwiI0TrUtGEZYbBC7g7p58%2FemDjfZGKk%3D&reserved=0.
midrange.com
