[xmlrpcflash-development] Fwd: [xmlrpcflash - Open Discussion] secure functionality with Flash xmlrpc

[Isaac L. <is...@st...>]

Begin forwarded message:

> From: Martin Redington <m.r...@uc...>
> Date: Tue Nov 26, 2002  9:26:48 AM America/New_York
> To: Isaac Levy <is...@st...>
> Subject: Re: [xmlrpcflash - Open Discussion] secure functionality with 
> Flash xmlrpc
>
>
> On Tuesday, November 26, 2002, at 06:41 AM, Isaac Levy wrote:
>
> Hi Isaac,
>
>> Hello Martin,
>>
>> Sorry this email is getting messy, but it's a lot of complex info to 
>> discuss...
>
> :-) Feel free to cross-post back to the forums, or forward. I'm sure 
> that this discussion might be of wider interest.
>
>>
>> right- but xmlrpc is weird, because when used in strict adherence to 
>> the spec, the incoming server knows to process the http request based 
>> on a 'Content-Type' header value of text/xml, in a POST operation.  
>> It was designed this way so that app servers could serve html and 
>> xmlrpc, (and etc...) over http- and the server could handle the 
>> different requests properly.
>>
>> Why HTTP auth wasn't included (just for kicks even), well, I don't 
>> really know.
>
> The "Header Requirements" section of the spec (included below) is far 
> too vague (IMHO).
>
>> Header requirements
>>
>> The format of the URI in the first line of the header is not 
>> specified. For example, it could be empty, a single slash, if the 
>> server is only handling XML-RPC calls. However, if the server is 
>> handling a mix of incoming HTTP requests, we allow the URI to help 
>> route the request to the code that handles XML-RPC requests. (In the 
>> example, the URI is /RPC2, telling the server to route the request to 
>> the "RPC2" responder.)
>>
>> A User-Agent and Host must be specified.
>>
>> The Content-Type is text/xml.
>>
>> The Content-Length must be specified and must be correct.
>
> I believe that it should actually read something like this (maybe 
> expanded a little).
>
>     Any valid POST request is a valid XML-RPC request, with the 
> following conditions: Content-length MUST be specified and correct.
>     Content-type SHOULD be set to "text/html" and User-agent and Host 
> SHOULD be specified. The URI must be valid.
>
>     The URI can be used by the server to route the request to the 
> XML-RPC service.
>
> Why is this better?
>
> Content-length is the only "useful" field. Your xml-rpc handler is 
> going to choke on the payload if its not in the correct format, 
> regardless of the Content-type header value. Similarly, User-agent and 
> Host are not required for correct operation. Why make them mandatory?
>
> This allows all of the facilities of http to be "inherited" 
> transparenty. E.g. 302 redirects, http auth, etc.
>
> Of course, some implementations might not provide access to these, or 
> to arbitrary header manipulation, etc., but these are poor 
> implementations, IMHO.
>
>>>
>>>>  I've been told several xmlrpc implimentations DO support 
>>>> user/password auth using this method, but I don't know specifically 
>>>> which ones.
>>>
>>> The jakarta xml-rpc lib does.
>>
>> Cool.
>>
>>>
>>> We believe that if you auth in the browser that flash is running in, 
>>> flash will carry that over to http xmlrpc requests to the same 
>>> domain that it was auth'd against.
>>
>> Well, you got me here!  I didn't think of that-  It would require 
>> just one HTML page for login, etc...  Heh!  Great.
>
> In fact, even that isn't required.
>
> A little known feature of the URI spec allows username/password to be 
> specified as part of the URI:
>
> protocol://user:pas...@su...d:port/path
>
> e.g.
>
> http://username:pas...@ww...:8080/index.html
>
> This appears to be supported by flash and jakarta's xmlrpc 
> implementations.
>
>> I would LOVE for flash to have the ability to read(and write) header 
>> infoirmation properly.
>> Regardless- xmlrpc servers are created to have Fault-Codes returned 
>> for different values.  This is specified here:
>> http://www.xmlrpc.com/stories/storyReader7
>
> It is pretty poor that it doesn't.
>
>> but different servers impliment slightly different response/fault 
>> codes.  It is expected that in your server you would be able to 
>> define a fault code, and define what to do with it in the client 
>> application.
>
> faultCodes look interesting, but the jakarta implementation doesn't 
> seem to support them very well. We don't use them for errors, as we 
> want to pass all kinds of debugging information back in failed 
> requests. We try to catch all exceptions at the server, and then pass 
> back an error object containing stack traces, the original arguments, 
> and error codes and messages.
>
> This makes debugging a *lot* easier (as you can read everything off 
> the client, instead of having to scan through the server logs).
>
>> OK- I'd love to post any notes or recipies you make on sourceforge!  
>> Good luck!
>
> Feel free to extract from mails. If we have any useful stuff later, 
> I'll forward it on ...
>
>    cheers,
>         Martin
>
>
>