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

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

Hello Martin,

Sorry this email is getting messy, but it's a lot of complex info to 
discuss...


On Monday, November 25, 2002, at 08:15 PM, Martin Redington wrote:

> Hi Isaac,
>
>     thanks for the prompt reply ...
>
> On Tuesday, November 26, 2002, at 12:24 AM, Isaac Levy wrote:
>
>>> we are developing the server side of an xmlrpc based application.
>>
>> Ah, with what?  (In the future, we'd love any write-ups on using 
>> xmlrpc and flash with different servers...)
>
> On the server side, we're using the jakarta xml-rpc implementation, 
> with tomcat ...

GREAT.  Would love to see what yall' come up with re. Flash/xmlrpc- if 
you wrote up something on your experience, I'd be sure it goes up on 
sourceforge...

>
>>> Our partners are developing the client side in Flash, using the 
>>> xml-rpc library.
>>> We are keen to use standard HTTP auth mechanisms and SSL, but they 
>>> are having
>>> great trouble with this.
>>
>> I understand this issue.  There are a couple of methods, but they are 
>> processes outside of the direct scope of xmlrpc:
>>
>> First, encryption:
>>
>> 1) use https for flash's server communications, but this only works 
>> when the SWF is played in a web browser.
>
> I think this is our deployment scenario, so we should be ok ...
>
>> Second, Secure Auth:
>>
>> 4) HTTP basic authentication (header based) is not covered by the 
>> xmlrpc spec itself, and any implimentation of it is outside of the 
>> scope of xmlrpc.
>
> I would expect it to transport auth transparently, as xml-rpc is just 
> built on top of http, and auth is part of the http spec (IIRC)

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.

>
>>  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.

>
>>> Having looked over the documentation and source code myself, I can't 
>>> see any
>>> support for Auth methods (e.g. setBasicCredentials) in the xmlrpc 
>>> lib, or the
>>> underlying XML object (which is used for transport, via the 
>>> sendAndLoad method).
>>
>> Right.  As we are in the process of reviving an 18 moonth old Alpha 
>> software, could you possibly give us any pointers as to how you'd 
>> like to see them implimented?
>
> well, in an ideal world, the xmlrpc object would have a setCredentials 
> method, that takes realm, name and password arguments. When the xmlrpc 
> object gets back a 401 or 403 (I forget which it is), it should send 
> the credentials up in the http headers.
>
> I suspect that this will be difficult to do if you use Flash's XML 
> object, as it doesn't appear to provide access to the request headers.


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/storyReader$7

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.

>
>> I have been discussing that an alternate 'switch' for making the 
>> xmlrpc object simply switch from http to https would be nice, 
>> (assuming browser usage), as well as simple to impliment.
>
> I would have expected this to happen transparently, according to the 
> protol specified in the url ...

Ah- well, it would need to happen in the flash file itself, as the 
flash file calls the server using whatever sendAndLoad etc... method 
you use, and in xmlrpc, the url for the server needs to be defined.

>
>> Authentication methods, however, would be futile- as they manifest in 
>> so many varied ways, it would be far outside of the scope of xmlrpc 
>> to include them- but can be a part of the flash application, and 
>> wrapped in an xmlrpc post.
>
> This is the whole point of http auth. Its standard and 
> well-understood, and anything that uses http should be able to support 
> it, including the http transport used for xml-rpc, and the webservers 
> that will typically be used as containers for xml-rpc services.

Right- and while the http auth. is standard, I don't think Flash 
supports it by itself.  However,
1) if the URL specified in the xmlrpc object is https
2) the movie is being played in a browser which is running https
3) the user has logged-in using html first

Then all should work just fine.

Based on what you stated above, I think that's the way (logically).  
But, if there is some other (completely flash based) way of doing this, 
I'd LOVE to know.


> In our java client (which we use for testing), adding http took one 
> line of code, and a few minor server configs ...
>
>>> I also noted in some more general Flash security documentation, that 
>>> XMLSockets
>>> do not support SSL,  and that the suggested fix is to roll your own 
>>> MD5
>>> encryption.
>>
>> Totally great- any info/URLs you have on this, I'd very much 
>> appreciate looking at!
>
> Try http://www.macromedia.com/desdev/mx/flash/extreme/extreme003.html
>
> or http://www.macromedia.com/desdev/mx/flash/whitepapers/security.pdf)
>

Thank you for the urls!  Great!

>
> I'll try and make sure that we get some feedback to the project ...
>
>     cheers,
>            Martin
>

OK- I'd love to post any notes or recipies you make on sourceforge!  
Good luck!

Best,
Isaac



   Isaac Levy
+ Office of Structured Systems
   http://structuredsystems.net