Flutterby™! : MS-Insanity for SOAP/XML and Auth 2007-11-29 23:26:15.793617+00

MS-Insanity for SOAP/XML and Auth

2007-11-29 23:26:15.793617+00 by meuon 5 comments

I'm building 1 simple XML gateway and one.. well complicated is an understatement, in XML/SOAP gateway, and I have to say good things (so far) about PHP's SOAP implementation, and a useful simple thing called: wsdl2php which makes calling a "WebService" via SOAP pretty easy. Even one written in .NET on MSIE and MS-SQL.

Now for the insanity. The 'WebService' I need to communicate with is pretty darn important, it should be locked behind firewalls and tunnels to do what it needs to. It was written by a 'Major' IT company and only runs on MS-SQL/IIS/.NET

This is their idea of security and authentication:

It won't work on https/ssl for some reason (It says so in their docs),
You get an authentication key (32 chars long) by doing an XML post to 'UserManager.asmx' with no login/password/ip or other info. It returns the 32 char key.
This key expires in 60 minutes..
All operations for the next XX minutes are 'authenticated' by handing back this key with other data in future requests..

I tried to figure out why not run 'simple auth' aka 'basic auth' on the web server, and I find out why: SOAP has an XML-ish version that works like this? which is usually post webserver handling/auth of the put.

Is it just me, or is SOAP a good idea gone bad?

The standard content encoding for HTTP POST gives a reasonable way to encode data for calling items that are accessible by URLs. What do SOAP (horrendously bad) and XML-RPC (sucks less) do? Completely redefine how they pass in data.

What needed to be specified for doing RPC stuff over HTTP? Unless you wanted to get really silly about complex data structures (which Microsoft did), only the return data format.

SOAP is a matter of some newbie academic coder deciding that they had to shoot a beer can to the moon rather than build a reasonable tool to do RPC over HTTP. It makes things transparent, and possibly easier, if you use Microsoft tools and only Microsoft tools to solve problems, but if you try to mix and match, it sucks.

And why does that suck? Well, I've had to debug a SOAP connection gone bad that ended up being a problem in router firmware in a little box that was in Hong Kong. Reading Ethereal captures of SOAP messages while trying to find the magic byte sequence sucked. Anything beyond toy demos requires getting down and dirty. If you're willing to entirely be at the mercy of one vendor you can whine to them when it doesn't work, but then you're at the mercy of that vendor.

Some companies can work that way. Some people like to work that way (we end up pawning development off on Apple occasionally because we pay for the super duper amazing level of developer tech support, and that's how you use 'em), but I'm too impatient to do much of that.

Dan, the problem is there are darn few of us that understand what's happening for real in a world of magic black boxes.

#Comment Re: made: 2007-12-02 16:41:59.730716+00 by: meuon [edit history]

I have to admit, I'm liking PHP's SimpleXMLElement function for parsing incoming XML, although currently I'm hand building most of the params for the requests, But there is something terribly wrong about world (like Microsoft's and these programmers of a system) that represents timezones as 32 character GUIDS:

and says that to convert to to and from a time zone, you post the guid of the source time, and the guid of the destination time to a SOAP service, and it will respond with an XML response of the correct time. No, there is no "time zones" or UTC-5 type of data..

Ouch. I sympathize. GUIDs can be a good idea, but Microsoft's use of GUIDs for data that should be human readable often makes me want to resort to violence...