Andrew Ho [mailto:[EMAIL PROTECTED] wrote: > > What I've seen on some applications is for a client to pass in > > arbitrary SQL code to the server which is then executed. > This is what > > is undesirable. It is not what you are doing, thus my "dangerous" > > statement doesn't apply. > > I see what you mean by "calling arbitray code". At some > level, any parameter being passed into any application can > cause un-intended effects. Applications (inclusive of all > code to the bare CPU) must deal with the uncertainties > associated with "programmability".
Err, if the application is properly and carefully written, paraneters should not cause unintended side effects. It is the (onerous) duty of the implementor to guard against this. But in practice, it happens all the time - witness the hundreds of "buffer overflow" or "unchecked buffer" exploits by viruses and worms. > > ... > > >Robustness requires many more considerations than > interface. Staying > > >with our discussion about application interface, an URL-callable > > >interface has important usability advantages. > > > > But has poor security management. Which is why standards such as WSDL are beginning to take off (as imperfect and technically ugly as they are). CORBA is another, technically excellent interface standard through which security mechanisms can be specified, but alas it never really took off. As has been discussed previously, "network effects" dominate technical excellence when it comes to interoperability standards, whether the subject is Web services or word processing document formats. Sad, but true. One only has to look at the near universal use of that dog's breakfast called HL7 2.x to realise that (yes, HL7 3.x promises a far more elegant morning meal...). Tim C
