Since a web service is hosted by an HTTP server e.g. Apache, then rather
than a roll your own authentication, it makes good sense to simply
configure the server to require Basic Authentication.
Then it is the responsibility of the client to ensure that each request
contains the appropriate credentials, which a browser client supports
automatically via it's private cache. Non-browser clients would need to
include a procedure to add credentials to the HTTP request header for
each request just like a browser does automatically.
Peter
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Walden H. Leverich
Sent: Wednesday, 11 February 2009 11:29 a.m.
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] my first web service
A web service can return any text you want it to (or binary w/DIME, but
we won't go there). It's not going to return a "result set" in the SQL
sense of the term, but there's no reason it couldn't return a list of
records. The rows could be a full-on XML representation:
<orders>
<order id=1 date='1/1/2009' customer='11111' /> <order id=2
date='1/1/2009' customer='22222' /> <order id=3 date='1/1/2009'
customer='33333' /> <order id=4 date='1/1/2009' customer='44444' />
</orders>
Or the result could be just a list of comma separated text:
1, 1/1/2009, 1111
2, 1/1/2009, 2222
3, 1/1/2009, 3333
4, 1/1/2009, 4444
etc. It's up to you to represent the data in a way that can be consumed
by your customers.
As for security. There are several main schools of thought, and each one
has its merits and uses.
1) Don't secure it. Possibly acceptable in an internal network where you
tightly control both ends.
2) Add a web service to "login" to your system. That service takes a
secret (username/password) and returns a session id. Then every other
service takes the session id (usually as the first parm) and validates
it. Throwing if it's not valid.
3) Perform the same "session" management using cookies, or a similar
construct. This depends more on your deployment infrastructure.
4) Pass the shared secret (username/password) on each call. Then you
don't need to worry about sessions, you just validate the secret each
time.
There are also approaches using client-side certificates, but I've found
those to be more trouble then their worth.
-Walden
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To
post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
#####################################################################################
This correspondence is for the named person's use only. It may contain confidential or legally privileged information, or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Veda Advantage. If you need assistance, please contact Veda Advantage on either :- Australia 133124 or New Zealand +64 9 367 6200
midrange.com
