Re: put in safety my Rest Web Services

Possibly something like this in concept:

Call to your API to authenticate user and create session info in table
(sessionid, actualuser, sessioncreatedtime, sessionexpirestime, sourceip
perhaps, whatever else you want to store for sesson ?)
http://1.1.1.1/webapi?action=login&uid=user&pwd=pass

Extract returned session ID from HTTP return data stream. Login call can
also be used to remove previous sessions for this user before generating
session.

I like using GUID as session IDs or some other long random string

Call to your actual API with session ID
http://1.1.1.1/webapi?action=getcust&cust=100&sid=sessionid

If a bad session ID, no data returned.

The XMLSERVICE CGI interface works similarly except I think you have to
pass user/pass with each call.

I've used this concept before and it seems to work fine.

Feel free to point out holes :-)

Have fun.

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn

----------------------------------------------------------------------

message: 1
date: Mon, 17 Aug 2015 19:42:23 +0200
from: "p.Caroti" <p.caroti@xxxxxxxx>
subject: [WEB400] put in safety my Rest Web Services

Hi



I have written and published some web Services to send and receive data
from App (Android and iOs) ; at this moment anybody that know System I ip
address and web service name could send and receive data from my System i.
My question is how could protect the Web Service's call . I was thinking
to a dynamic password linked to date and time passed as parameter in uri ..
Which technique do you use in this situations ?



Thanks in advance


--
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: 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.