[cgiapp] Best practice for CGI errors
mark at rawcane.net
Mon Sep 22 11:56:11 EDT 2008
> Mark Knoop wrote:
>> ...while I am here (and acknowledging that this is slightly off topic but
>> at the same time it is probably somehting that many of you have had much
>> experience in 'real-world' scenarios) can I ask whether CGI::App users
>> have any favourite ways to do it re 'web services' ie remote methods/apis
>> that do something then return some data? SOAP, XML-RPC, bespoke
>> XML/JSON/other in response to GET/POST with CGI params, any other
>> approach? My methods and responses are very simple.
> For simplicity (speed, human readability, etc) you can't beat JSON. I love
> it. And if you allow some JSONP you can make it easy for people to use
> your service to build mashups. You can have your clients make submissions
> that are simple requests with a JSON document as part of the request or
> you can use normal CGI style parameters. Really up to you.
> I'd avoid SOAP if I were you. It's overly complex and there are a lots of
> different variations. Compatibility between systems is not given and can
> be a real big headache.
>> It would be nice to have hassle free security already there - this was
>> the one advantage to SOAP - the main disadvantage being a lack of
>> understanding on my part...
> I could be completely wrong, but I don't see how SOAP provide security to
> your application? You still need to implement whatever security scheme you
> decide on and you can always use SOAP's basic security model for your own
> application if you want. But as far as security in web services goes I've
> had good success with the following:
> 1) username and passwords. Treat it just like other web stuff. The only
> difference is that you don't really use a cookie, you just make them send
> the username and password on every request.
> 2) crytographic token. Very similar to #1 but instead of passing a
> username and pw with each request it's just a simple token. You'd give
> each client a separate token which you can then verify on each request.
> You can also embed data into the token itself like client id, etc. You can
> even embed something like the origin IP address in there so that client
> can't give your tokens away to other people.
> Michael Peters
> Plus Three, LP
Thanks for this. I like the look of JSON(P)... will investigate further as
an alternative to XML. Re SOAP security it was just that I had working
examples of clients accessing a proxy via ssl but I guess that there is no
reason why I cannot use https with a normal CGI request - I just never have
done (or at least not with a dynamic client as opposed to a browser).
Username and password just get passed as normal parameters so as long as
they are ssl'd that's fine.
More information about the cgiapp