[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> It's radically different because there is no easy way to
> build a bridge
> from form posts to arbitrary COM objects, is there? It takes
> effort. It
> takes mediation. The extra effort introduces a layer of indirection
> which makes security holes less likely.
Well, you are right that there are no wizards (AFAIK) to expose a COM
interface via a form post. But writing an ASP page to do so is actually
quicker an easier than those hyped wizards for exposing a COM interface.
(And as an aside, I totally agree that designing a web service by
mechanically exposing an implemenation is a bad approach. James Snell has a
nice little article on xml.com that points to the pitfalls with this
approach [1] with regard to interoperability. This approach is not likely to
be sustainable, although he doesn't seem to draw that conclusion.)
<snip/>
> Think about it...all of the infrastructure software companies in the
> world are working together to sell FIREWALL SUBVERSION TECHNOLOGY. And
> they advertise it as such. Doesn't that seem a little strange
> to you???
OK. I see your point. But I would still say a couple of things about this.
Making it "easy" to get through the firewall is not the same as
"subversion". The SOAP spec even offers a header explicitly for filtering at
the protocol layer: the SOAPAction header. I understand that in practice,
use of this header is rather uneven. But it seems to have been an explicit
attempt by the spec writers to provide visibility to the firewall, among
other things. I'd be interested in your opinion on this. Would it help if
implementations treated the SOAPAction header more seriously, or was that
proposal a misfire to begin with?
The fact that tools by certain vendors promote questionable approaches is
not the same as the standard itself being flawed. Rather than fixating on
Microsoft's tools, I'd rather hear analysis focusing on the spec itself.
Remember, this is the vendor that told us customers *want* to get emails
that can run code on their systems. Does that mean email itself is
inherently insecure? I don't see one vendors tools or marketing hype as an
indictment of SOAP itself.
It seems like several issues are getting muddled. But I will confess that
the thought of newbie programmers picking up those Visual Studio wizards and
exposing web services scares me, too. I think drawing clearer delineations
between implementations and the spec itself would help the credibility of
analyses.
BTW, you must be getting tired by now, Paul. ;-) I appreciate you comments,
though. This has been quite a debate.
[1] http://www.xml.com/pub/a/2002/01/30/soap.html
|
