xmlrpcflash-development — A developers list for core development of the xmlrpcflash client library.

Re: [xmlrpcflash-development] return values (was: help!)

[Ed C. <ed...@gr...>]

On Sat, 8 Feb 2003, Isaac Levy wrote:

> This has been a problem with this library since I joined this project.
> Basically, the xmlrpc post/request methods are terrific, but the return
> results leave a lot to be desired.  Many xmlrpc libraries return
> objects native to a given language, but this library hasn't gotten
> there yet.

What if we were to enforce a standard on return values, like a python
dictionary, or list of dictionaries.

The python xmlrpc library is really easy to work with in this regard
because every return value looks the same.  Even if it's a single value,
it's wrapped in a single value list, then in a dictionary.

I'm just a newbie at actionscript, so excuse my ignorance, but can't we do
the same thing here?

What is the actionscript equivalent of a python dictionary anyway?  Just a
multi-part array?

Lets get this last hurdle locked down so we can all rock it.

-e-

-- 
Green Graphics   :::   Print and Web Design   :::   510.923.0000

Re: [xmlrpcflash-development] help!

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

Hello Paulo,

This has been a problem with this library since I joined this project.
Basically, the xmlrpc post/request methods are terrific, but the return =20=

results leave a lot to be desired.  Many xmlrpc libraries return =20
objects native to a given language, but this library hasn't gotten =20
there yet.

I would suggest the following resources to help parse the xmlrpc =20
response:

A great standards-compliant xml parsing library:
http://xfactorstudio.com/projects/XPath/

And from the horses mouth:
http://www.macromedia.com/support/flash/action_scripts/objects/=20
xml_object.html


At the moment, I wish I could instruct you how to use a builtin object =20=

aquisition library, but we aren't there yet.

I would love to invite you, if you are working with the library, to =20
join this mailing list- and please post good results!

Best,
.ike





On Friday, February 7, 2003, at 11:33  AM, Paulo wrote:

> hi everybody!
> =A0
> im in a trouble, i have little experience with xml-rpc and flash and i =
=20
> can't get the results from my connection.
> =A0
> actually, i start a connection with a python server, and set up a =20
> server. i can send the data, the server reads and treats it and return =
=20
> it to me, but i donk know how to acess it!
> =A0
> a dont know how to read the properties from the resulting value, cause =
=20
> i dont know where they are stored.... the lib uses the actionscript =20=

> method called loadAndSave, and then i dont know from where i can read =20=

> the data...
> =A0
> thanx in advance folks!!
> =A0
> =A0

[xmlrpcflash-development] help!

[Paulo <pa...@ps...>]

hi everybody!

im in a trouble, i have little experience with xml-rpc and flash and i =
can't get the results from my connection.

actually, i start a connection with a python server, and set up a =
server. i can send the data, the server reads and treats it and return =
it to me, but i donk know how to acess it!

a dont know how to read the properties from the resulting value, cause i =
dont know where they are stored.... the lib uses the actionscript method =
called loadAndSave, and then i dont know from where i can read the =
data...

thanx in advance folks!!

Re: [xmlrpcflash-development] new Flash Player beta has ContentType working

[Ed C. <ed-...@gr...>]

Well, lets hope that content type fix lasts.  =)

If you haven't already done it, I can spend s few minutes with a windows
version.  Can't wait for flash for lynx.  =)

I'm embarking on a big flash project and I'll be using xml-rpc pretty
heavily for it...  I hope!  I've also been playing with swocket, that's
pretty nifty, but could be a major headache getting it to play nice with
zope.  Also pretty wasteful for this application.

anyway, on to the coding!

-e-


On Sun, 8 Dec 2002, Isaac Levy wrote:

> Good News has been posted here:
>
> https://sourceforge.net/forum/forum.php?forum_id=233982
>
> regarding the new Flash plug-in beta, which I have successfully tested
> to now have ContentType working (!!!)  Details can be read in the news
> post on sf, and as I have only tested this on a Mac, (OSX.2.2), I am
> definately looking for anyone who is interested in testing on Windows
> and Linux- and can provide .fla source files, as well as a server to
> provide test response.
>
> Best,
> Isaac (dot_ike)
>
>
>
>    Isaac Levy
> + Office of Structured Systems
>    http://structuredsystems.net
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> //
> //  xmlrpcflash-development mailing list
> //  xml...@li...
> //  http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>

-- 
Green Graphics   :::   Print and Web Design   :::   510.923.0000

[xmlrpcflash-development] new Flash Player beta has ContentType working

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

Good News has been posted here:

https://sourceforge.net/forum/forum.php?forum_id=233982

regarding the new Flash plug-in beta, which I have successfully tested 
to now have ContentType working (!!!)  Details can be read in the news 
post on sf, and as I have only tested this on a Mac, (OSX.2.2), I am 
definately looking for anyone who is interested in testing on Windows 
and Linux- and can provide .fla source files, as well as a server to 
provide test response.

Best,
Isaac (dot_ike)



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

[xmlrpcflash-development] xmlrpc testing bin?

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

Hello All,

Begin forwarded message:

> if you guys so desire, I can set up a testing area on one of our 
> servers we all can share- just for uploading and testing against dummy 
> auth accounts.

Would anyone find this useful? If so, I can set up some basic services 
really quickly-
but I won't spend any time until I hear a shout for it-

Best,
Isaac



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

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

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

Hello Again Martin, All,

Back and rockin' after a thanksgiving hiatus...
Some of the below comments on the Content-Type issue are a bit off 
subject (in lieu of directly working on the current flash lib), but I 
thought this would be a good moment to dive into this issue:


On Wednesday, November 27, 2002, at 05:50 AM, Martin Redington wrote:

>
> On Tuesday, November 26, 2002, at 10:59 PM, Isaac Levy wrote:
>>
>> Agreed.  There are some shortcomings inherent in the spec.
>
> I think that they could be fixed fairly easily. RFC style 
> (http://www.ietf.org/rfc/rfc2119.txt) gives an approriate level of 
> precision for spec docs.
>
> The current spec isn't quite at that level of precision.

Yep.  Agreed.

> ...The simplicity of xmlrpc over SOAP (which I've hardly looked at 
> all, to be fair) won us over pretty quickly.

;)


>>>> Header requirements
>>>
>>> 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?
>>
>> Ah, if I have your question right, I have an answer from my 
>> experiences-
>
> I figured it might be something like that, but those are historical 
> reasons, not proper motivations for the spec (except that where 
> possible, the spec should not break backwards compatibility).

Well, I'm not really just drawing from my experiences here, (in 
personally mandating implimentation of the Content-Type header), but it 
comes from fundamental differences in modes of operation, between 
various xmlrpc mechanisms.

I have posted a quick generalized diagram here:
http://xmlrpcflash.sourceforge.net/diagram/xmlrpc_server_types.jpg

It illustrates one main point- that server applications which are 
designed to deal with calls in different contexts, the Content-Type 
header and POST are needed, to distinguish the xmlrpc call, from other 
http calls (i.e. html form POST data, etc...).

It is my understanding that this is how Userland's server software 
distinguishes between incoming http calls (to enable certain actions to 
be taken from both an administrative web browser, and their xmlrpc 
desktop app, [all over http- and over one port]).

Now, for a strict xmlrpc server, it could be set-up to manipulate the 
same back-end data, (i.e. a database, whatever), but then the server 
would need it's own port, [defeating the idea of being able to run 
xmlrpc over port 80, while serving html over port 80 as well]).

>
>> --Now, I use Apache to Proxy Zope and do a lot of server 
>> heavy-lifting, so my Flash solution was to use the Apache2 
>> Request-Set-Header directive, and create a subdomain for xmlrpc 
>> requests.  It simply and reliably injects the header before the POST 
>> reaches my app server.
>
> This is exactly my point, kind of. Your container might want to all 
> kinds of funky manipulations on the requests headers and URI before 
> handing them to xmlrpc to process. xmlrpc should only *require* 
> headers that it *actually requires* (although others may be 
> encouraged).
>
> A good (as in easy to work with) xmlrpc server implementation (the 
> xmlrpc part, not the container itself) shouldn't *require* the 
> Content-type header (or should at least allow it to be optionally 
> ignored) because if its been handed a call, that call is almost 
> certainly xml, and if it isn't, it will be caught downstream during 
> parsing anyway. Content-type: text/xml should be a SHOULD or MAY item, 
> rather than a MUST. This would save you having to fiddle with 
> Request-Set-Header for a start.

Well, based on my above explanation, I respectfully step back a bit;
though the Content-Type header is irrelevant when applied to specific 
servers which are meant ONLY for xmlrpc, this does not seem to be 
common practice in the construction of servers, as they are commonly 
designed to serve and use the same sets of data in different 
technological contexts.

Therefore, although it is not always necessary for the client to have 
Content-Type set correctly, it is necessary in order to work with a 
great number of xmlrpc-aware application servers (in the context of 
running all that http over common port 80- or even over https on common 
port 443).


> Similarly, irrelevant headers should be silently ignored, and this 
> should be explicitly specified in the spec. The container may be using 
> these to do all kinds of stuff (e.g. http auth).
>
> Good quality client implementations will allow access to header 
> manipulation, and this should be a SHOULD item, and strongly 
> encouraged in the spec.

Right.

>> Yep.  MM has decided to hold those keys, but to give a bit of the 
>> benefit of the doubt to MM, I'm assuming it also keeps the 
>> plugin-size small.
>
> I can't see it adding very much to the binary size. Its just setting a 
> string at the end of the day.

I agree.

>
>> So, in the end, it seems to me that the source of a lot of the 
>> problems with flash is an Open/Closed conceptual rift.
>
> Its their right, as a commercial organisation, to restrict customer 
> flexibility in order to encourage sales of their premium products, 
> although I suspect that they wouldn't lose many customers by opening 
> up access to request headers in the XML object.

I agree strongly here too.

> But its also a good reason to mark implementations which don't support 
> access to the functionality of the underlying HTTP protocol as poor 
> ones.

Well, yes- but defining this at the spec level does make for a bit of 
fragmentation, (as the general objective is that all xmlrpc speaks to 
all xmlrpc).
This will be noted as more documentation for the flash lib is created, 
as this issue must be clearly and simply addressed on the sourceforge 
side of things.

> It would be nice if the open libraries did this, but if you're using 
> XML.sendAndLoad, you might have problems. One option might be to 
> provide your own http lib which users can switch to if required.

How do you mean here?  This sounds interesting(?).


Best,
Isaac



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

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

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

Hi Danny,

On Wednesday, November 27, 2002, at 06:22 AM, Danny Angus wrote:
>
>
>>> The URL RFC defines a URL as
>>> protocol://user:pas...@su...p-leveldomain/path
>>>
>>> However the HTTP sub-spec of this RFC removes the username:password
>>> from the spec for HTTP.
>
>
>> I was testing it in a browser earlier.  argh...
>> I haven't tested it yet, but I'm assuming that seeing as there is no
>> way to insert username/pass for basic http auth, that flash doesn't
>> automatically put them there in the same way which browsers circumvent
>> the HTTP RFC URL sub-spec change.
>
> But if flash is somehow using the browser to make the http requests 
> (which may explain why you can't manipulate headers) it may pass the 
> user:pass up to the browser, which *does* know how to use it. (fingers 
> x'ed)

OK, this needs to be tested more asap.
I've just done it from straight outta flash right now... a standalone 
swf, in the flash player, does pass the proper credentials to the 
server in the following form:
http://username:pas...@se...:80

this using Flash's .sendAndLoad mechanism.

HOWEVER, when I placed the file up on the server to test it from a 
browser, it did not seem to work- as it seems that the web browser was 
overriding the flash file's authenitication call (header settings...)
Oy.  This is unexpected.

>
>
>> Q- do you have any links to a good readable version of the http
>> sub-spec of the URL RFC?
>
> Try some of the other formats on this page http://www.w3.org/Protocols/

thx-

>
>> OK- back to sqare 1 here.
>> Danny, do you have any suggestions re. how else everyone can proceed
>> here, strategies etc...?
>
> Not really, I don't know enough about flash to see how it's preparing 
> the http request.
> Some insight into SendAndLoad() might help, but not necessarily.

We all need to investigate the way Flash handles SendAndLoad in greater 
detail.  My little experiment (above) with http auth just showed me 
that Flash behaved the very opposite of how I expected it to, and there 
must be reasons for it.

As for me (and my colleague Chad), it's well over the end of our day 
here, and the US Thanksgiving holiday weekend is upon us- (not sure, 
but I'm assuming yall' don't celebrate it across the Atlantic...)
With that, we'll all be fairly un-reachable until this coming Monday.

At that point, if you guys so desire, I can set up a testing area on 
one of our servers we all can share- just for uploading and testing 
against dummy auth accounts.

>
> A little, but I'm really more interested in email 
> (http://jakarta.apache.org/james)
>

mmm... This is very cool- makes me wish I didn't need to sleep...<g>

Best,
Isaac



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

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

[Danny A. <da...@ap...>]

> Great- the more cross-posting, the merrier!  (Are you in England as=20
> well?)

Almost, 400 miles north of Martin in Scotland.


> > The URL RFC defines a URL as=20
> > protocol://user:pas...@su...p-leveldomain/path
> >
> > However the HTTP sub-spec of this RFC removes the username:password=20
> > from the spec for HTTP.


> I was testing it in a browser earlier.  argh...
> I haven't tested it yet, but I'm assuming that seeing as there is no=20
> way to insert username/pass for basic http auth, that flash doesn't=20
> automatically put them there in the same way which browsers circumvent =

> the HTTP RFC URL sub-spec change.

But if flash is somehow using the browser to make the http requests =
(which may explain why you can't manipulate headers) it may pass the =
user:pass up to the browser, which *does* know how to use it. (fingers =
x'ed)


> Q- do you have any links to a good readable version of the http=20
> sub-spec of the URL RFC?

Try some of the other formats on this page http://www.w3.org/Protocols/

> OK- back to sqare 1 here.
> Danny, do you have any suggestions re. how else everyone can proceed=20
> here, strategies etc...?

Not really, I don't know enough about flash to see how it's preparing =
the http request.
Some insight into SendAndLoad() might help, but not necessarily.

An alternative may be to script the browser and make it do the work, but =
I don't think that even if it were possible it would be a satisfactorily =
robust solution.

> (I'm assuming from your email address that you might know about=20
> http...<g>)

A little, but I'm really more interested in email =
(http://jakarta.apache.org/james)


> For if not, I'd go back to suggesting everyone stick to doing some =
sort=20
> of auth system based on the content of the xmlrpc message (like =
Patrick=20
> suggested in the first place).
> Right?
>=20
> Thanks Danny, and everyone, for the Input here!
>=20
> Best,
> Isaac
>=20
>=20
>=20
>    Isaac Levy
> + Office of Structured Systems
>    http://structuredsystems.net
>=20

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

[Martin R. <m.r...@uc...>]

On Tuesday, November 26, 2002, at 10:59 PM, Isaac Levy wrote:
>
> Agreed.  There are some shortcomings inherent in the spec.

I think that they could be fixed fairly easily. RFC style 
(http://www.ietf.org/rfc/rfc2119.txt) gives an approriate level of 
precision for spec docs.

The current spec isn't quite at that level of precision.

> As an aside, the reason I like working with xmlrpc (over SOAP, for 
> now), is that it is so simple, and that the shortcomings are usually 
> simple to overcome.  Good for a reductivist development approach.
>
> It did make me interested in the SOAP spec, but this is SUCH a moving 
> target, and so many big hands are in the pot, that I don't see it 
> being practically implemented anywhere yet- (and haven't seen much 
> done with it).

In our case, I was looking at xwt (http://www.xwt.org) as a possible 
user-interface for another project. It uses xmlrpc for comms back to a 
server, much like an xmlrpc flash app.

The simplicity of xmlrpc over SOAP (which I've hardly looked at all, to 
be fair) won us over pretty quickly.

>>> Header requirements
>>
>> 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?
>
> Ah, if I have your question right, I have an answer from my 
> experiences-

I figured it might be something like that, but those are historical 
reasons, not proper motivations for the spec (except that where 
possible, the spec should not break backwards compatibility).

> --Now, I use Apache to Proxy Zope and do a lot of server 
> heavy-lifting, so my Flash solution was to use the Apache2 
> Request-Set-Header directive, and create a subdomain for xmlrpc 
> requests.  It simply and reliably injects the header before the POST 
> reaches my app server.

This is exactly my point, kind of. Your container might want to all 
kinds of funky manipulations on the requests headers and URI before 
handing them to xmlrpc to process. xmlrpc should only *require* headers 
that it *actually requires* (although others may be encouraged).

A good (as in easy to work with) xmlrpc server implementation (the 
xmlrpc part, not the container itself) shouldn't *require* the 
Content-type header (or should at least allow it to be optionally 
ignored) because if its been handed a call, that call is almost 
certainly xml, and if it isn't, it will be caught downstream during 
parsing anyway. Content-type: text/xml should be a SHOULD or MAY item, 
rather than a MUST. This would save you having to fiddle with 
Request-Set-Header for a start.

Similarly, irrelevant headers should be silently ignored, and this 
should be explicitly specified in the spec. The container may be using 
these to do all kinds of stuff (e.g. http auth).

Good quality client implementations will allow access to header 
manipulation, and this should be a SHOULD item, and strongly encouraged 
in the spec.

>>> 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.
>
> Yep.  MM has decided to hold those keys, but to give a bit of the 
> benefit of the doubt to MM, I'm assuming it also keeps the plugin-size 
> small.

I can't see it adding very much to the binary size. Its just setting a 
string at the end of the day.

> So, in the end, it seems to me that the source of a lot of the 
> problems with flash is an Open/Closed conceptual rift.

Its their right, as a commercial organisation, to restrict customer 
flexibility in order to encourage sales of their premium products, 
although I suspect that they wouldn't lose many customers by opening up 
access to request headers in the XML object.

But its also a good reason to mark implementations which don't support 
access to the functionality of the underlying HTTP protocol as poor 
ones.

It would be nice if the open libraries did this, but if you're using 
XML.sendAndLoad, you might have problems. One option might be to 
provide your own http lib which users can switch to if required.

> Hmm. That's a shame.  Well, it took 3 revision versions of Zope to 
> finally get fault codes in a sensible state- but in the end, it wasn't 
> that painful- and now, I am able to get python tracebacks and server 
> error messages with fault codes.

I don't think I've even seen any ... the jakarta client lib just seems 
to throw client exceptions if there's a problem, although it may be 
using fault codes under the hood (and most problems we've had are http 
level ones ... e.g. 401's).

> It is my understanding, (correct me if I'm wrong), that Jakarta is an 
> application Servlet which was created to work primarily with 
> Tomcat/Apache.

Jakarta (http://jakarta.apache.org) is the Apache Foundation's project 
for server side java. Their products include Tomcat, Ant, Struts, and a 
whole lot more.

> Right- and you can build your flash app to deal with a given error in 
> some sensible manner for the end user as well, or provide some sort of 
> feedback/logging mechanism to the server, etc....

exactly.

    cheers,
              m.

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

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

Hello Danny,

On Tuesday, November 26, 2002, at 01:26 PM, Danny Angus wrote:

> I'm working with Martin (In case you wondered where I came from!)

Great- the more cross-posting, the merrier!  (Are you in England as 
well?)

>
>> One more question-
>>   I'm assuming that the URI spec was itself implemented in the making 
>> of
>> the http spec, so, regardless,
>> Q. I am wondering if you know if there is something in the URI
>> specification to set the HTTP content-type header in a similar manner?
>
> The URL RFC defines a URL as 
> protocol://user:pas...@su...p-leveldomain/path
>
> However the HTTP sub-spec of this RFC removes the username:password 
> from the spec for HTTP.
>
> What this means in practice is that you are allowed to define a URL 
> with user/pass but the http client must convert it into http request 
> Headers per the HTTP AUTH rfc.
> Sorry..

/* ike winces and gnashes teeth */

I was testing it in a browser earlier.  argh...
I haven't tested it yet, but I'm assuming that seeing as there is no 
way to insert username/pass for basic http auth, that flash doesn't 
automatically put them there in the same way which browsers circumvent 
the HTTP RFC URL sub-spec change.

These are some really esoteric annoyances, eh?

Q- do you have any links to a good readable version of the http 
sub-spec of the URL RFC?

>
>> In the past, (and just now) I've tried doing this:
>> http://sub.domain.tld:port?Content-Type=text/xml
>> but no- go.
>
> It won't work, unless the client can xlate them, the user:pass is a 
> special case that can be used by clients instead of a login dialog.

OK- back to sqare 1 here.
Danny, do you have any suggestions re. how else everyone can proceed 
here, strategies etc...?
(I'm assuming from your email address that you might know about 
http...<g>)

For if not, I'd go back to suggesting everyone stick to doing some sort 
of auth system based on the content of the xmlrpc message (like Patrick 
suggested in the first place).
Right?

Thanks Danny, and everyone, for the Input here!

Best,
Isaac



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

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

[Danny A. <da...@ap...>]

Hi,
I'm working with Martin (In case you wondered where I came from!)

> One more question-
>   I'm assuming that the URI spec was itself implemented in the making =
of=20
> the http spec, so, regardless,
> Q. I am wondering if you know if there is something in the URI=20
> specification to set the HTTP content-type header in a similar manner?

The URL RFC defines a URL as =
protocol://user:pas...@su...p-leveldomain/path

However the HTTP sub-spec of this RFC removes the username:password from =
the spec for HTTP.

What this means in practice is that you are allowed to define a URL with =
user/pass but the http client must convert it into http request Headers =
per the HTTP AUTH rfc.=20
Sorry..

> In the past, (and just now) I've tried doing this:
> http://sub.domain.tld:port?Content-Type=3Dtext/xml
> but no- go.

It won't work, unless the client can xlate them, the user:pass is a =
special case that can be used by clients instead of a login dialog.

d.

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

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

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

Hi Martin-

On Tuesday, November 26, 2002, at 10:46 AM, Martin Redington wrote:

>>
>> 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.
>
> Actually, on further testing and experimentation, we're having trouble 
> getting this to work. We're just looking to find out why ...
>
> login via an html page seems to work though ...
>


Ohhhhh. Cool, Thanks!  That's another way I haven't thought of.  When 
you find out what the trouble is, I'd love to know... (do you think the 
trouble is Flash, or Jakarta?)

I just tried this with a Zope, and it does seem to work just fine 
(COOL).

I'm wondering if you feel that this would be a handy thing for us to 
implement in the xmlrpcflash .as, as a method for supporting Basic Auth?
(i.e. make some sort of way to specify URI based HTTP auth by, say, 
providing keywords in the xmlrpc object, and they'd get parsed into the 
URL to make the URI, so:

---start imaginary hypothetical snippet----------------------
// in the flash app:
#include "xml-rpc.as"
objXMLRPC = new 
XMLRPC("https://sub.domain.tld:port/",30,username:password);

// where the url for the xmlrpc server is specified,
// 30 is the timeout specified,
// and username:password will perform http basic auth- by letting
// the xmlrpc.as parse the actual URL it sends as:
// https://username:pas...@su...d:port/
---end snippet-----------------------------------------------

Q. Do you think this would make the actionscript easier for developers 
to use, or would you think it would make it more complex/confusing?

--
One more question-
  I'm assuming that the URI spec was itself implemented in the making of 
the http spec, so, regardless,
Q. I am wondering if you know if there is something in the URI 
specification to set the HTTP content-type header in a similar manner?

In the past, (and just now) I've tried doing this:
http://sub.domain.tld:port?Content-Type=text/xml
but no- go.  It doesn't trigger the xmlrpc mechanism on my server 
(Zope)- as it sets ContentType as form variables, not http header 
variables.
(Now, It is possible to re-write the request mechanism of Zope to 
handle the Post as xmlrpc based on an x-Content-Type http form 
variable, but that gets messy- and doesn't necessarily solve the 
problem in Flash- for other servers- so I've avoided this solution).

Anyhow, I'm sorry to ask so many questions of you here, (as you had 
questions for us in the first place,) but on this end, I feel this 
dialogue has become quite fruitful re. core auth details.

Best,
Isaac



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

[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

Re: [xmlrpcflash-development] Reporting success

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

Hey Ed,

On Tuesday, November 26, 2002, at 12:09 AM, Ed Colmar wrote:

>
> Hey Isaac and everyone else.
>
> I just grabbed the newest code off viewartwork, and tweaked it a bit to
> run on my zope.

Great!
[ Zopenote:
I pasted the python code for the external method below ]

>
> This is a super simplified test, as there is only one argument, and one
> response, but I do have a little project to work on that is really this
> simple...
>
> I'm passing one variable "name" off to the server that returns "hello
> /name/".  For 7 lines of code, its not too bad...  =)
>
> ------------------------- Snip --------------------------
>
> #include "xml-rpc.as"
> objXMLRPC = new XMLRPC("http://xml.siegerecords.com/",30);
>
> objtest = new XMLRPC_Object("string");
> objtest.AddMember("name");
> objtest.SetValue("duh");
>
> objXMLRPC.AddParameter(objtest);
> objXMLRPC.Call("xmlrpctest");
>
> ---------------------------------------------------------
>
> Now on to play with a little movie that uses it in this simple way...

I'm going to assume you are trying to impliment this in a useful manner  
now:

OK- for the moment, as Patrick has provided the patch that strips out  
all the (buggy) rsponse-hhandling methods,
http://sourceforge.net/mailarchive/ 
forum.php?thread_id=1275926&forum_id=12944

You'd then need in your response to grab the response method out of the  
xml returned,
(which you can get like so:
------------------snippet-----------------------------
// put somewhere in the second frame of the .fla file:
trace(objXMLRPC.methodResponse);
------------------end snippet-------------------------


> After that...  I'll need to get multiple return values figured out.

Right- if you call your created 'objXMLRPC.methodResponse', you get the  
raw xml, and can pull the variables out by making it a native flash xml  
object.

That's right where we're at, big picture stylin'.
Chad and I have been going through the xmlrpc spec for a good chunk of  
today, and comparing it to the base actionscript library- so we end up  
truly constructing useful objects from the return values.

Once that is sorted a bit better, we can create the return parsing  
methods- (with the intention of not making a user of the lib. have to  
parse xml- a time consuming dev. task...)

ANY xml parsing actionscript which you generate while working, would be  
much appreciated... and I'll be sure to post any useful snippets as we  
go along...

Rocket-
.ike



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







------------------snippet-----------------------------
------------------Zope/Python External Method---------
------------------Lots of comments...-----------------

"""
a server-response to generate most every xmlrpc object possible, for  
parsing
based on the server-response xml bundled with Patrick O'Lone's orignial  
xmlrpc client
for flash, 0.5 Alpha (http://xmlrpcflash.sf.net)
"""

import xmlrpclib
# import is only usefull when handling:
	# Boolean
	# DateTime
	# Binary data

ikenote="""
	This method is meant to mimmic the resoponse xml which
	came with Patrick's xmlrpcflash 0.5 Alpha.  This method
	is currently a work in progress, as I'm still not taking
	time to return multiple params, plus these 3 object types:
	
	DateTime, Boolean, and Base64 Binaries.
	"""


def test_response():
	## first, let's define some standard object variables:
	# an int or i4
	myServerIntiger=4
	# a double
	myServerFloat=4.9
	# a string
	myServerString='hello actionscript world'
	# an array
	myServerArray1=('one', 2, myServerFloat)
	myServerArray2=(myServerIntiger, 2, 'three')
	# a struct
	myServerDict={'foo':'eggs', 'bar':2, 'fooBar':myServerString}
	
	## the following values use the handy methods from xmlrpclib
	# boolean values (best to use the xmlrpc boolean values)
	##myTrue=xmlrpclib.True
	##myFalse=xmlrpclib.False
	# a DateTime value (dateTime.iso8601)
	##myTimestamp=xmlrpclib.DateTime()
	##myTimeWas=xmlrpclib.DateTime('19980717T14:08:55')

	# example Binary Value
	##myB64_obj=xmlrpclib.Binary('eW91IGNhbid0IHJlYWQgdGhpcyE=')
	
	
	#now let's make the response, (not fully using all of the above  
objects)
	# an example of an array with all the types:
	# string, int, (i4- same as int in Python), base64 (ikenote myB64_obj,  
missing here, double, dateTime, boolean
	##myParam1=('hello world', -12, -12, myB64_obj, -12.214, myTimestamp,  
myTrue)
	myParam1=('hello world', -12, -12, -12.214)
	# struct with nested array as struct object
	##myParam2={'lowerBound':18, 'upperBound':139, 'testArray':(12,  
'Egypt', myFalse, -31)}
	myParam2={'lowerBound':18, 'upperBound':139, 'testArray':(12, 'Egypt',  
-31, ikenote)}

	return (myParam1, myParam2) # this returns the <params>

------------------end snippet-------------------------

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

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

Hello there,

My name is Isaac and I'm a new Admin on this project-

On Monday, November 25, 2002, at 04:25 PM, no...@so... 
wrote:

> Dear all,
>
> 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...)

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

2) A hash can be made in Flash, (you mention MD5 later), but as hashes 
are a medium/lightweight encryption method- but they would do for good 
protection for general obfuscation.

3) For industrial-duity use, Run the xmlrpc connection through an SSL 
tunnel, (independent of both Flash and the server), though this would 
not be a desired method for heavy-use apps, as SSL can be process 
consuming, and managing keys/certs can be inappropriate for some 
applications)
Good starting points on this would be:
http://www.oreillynet.com/cs/weblog/view/wlg/499
http://www.tacc.utexas.edu/resources/user_guides/ftp/

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've been told several xmlrpc implimentations DO 
support user/password auth using this method, but I don't know 
specifically which ones.
Additionally, I have no info on how well Flash would be able to 
consistently perform http auth, as I have found it to have 
bugs/problems with inserting anything in the http header itself, (flash 
4 all the way up to MX),
One such problem is outlined here:
http://www.zope.org/Members/ike/Flash-Zope/FLASH_xmlrpc_zope/

5) If you do successfully augment the HTTP headers from flash, then be 
sure to use the 'X-' prefix, as defined in RFC 1521 
(http://www.ietf.org/frc/rfc1521.txt) to indicate their nonofficial 
nature- (not only for posterity, but trust me- annoying problems can 
arise as the messages fly across the net, if you leave off the X)

6) RECOMMENDED: Encrypt the entire transfer somehow, (using 
SWFhttps->browser->server) and devise some mechanism for password 
authentication between your flash client, and server applications.  
This has been a successful strategy for Zope xmlrpc users; one way has 
been to use:
http://www.zope.org/Members/natesain/RPCAuth


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

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.

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.

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

>
> Two questions:
>
> 1) Is there any way to use HTTP Auth with Flash xmlrpc?

I hope that I have covered this well enough above,

>
> 2) Are SSL connections supported with Flash xmlrpc, or (I guess if it 
> used XMLSockets
> directly or indirectly) will we need to plug in our own MD5.

XMLSockets and xmlrpc are 2 very different things.  XMLSockets are for 
creating perisistent connections to an appropriate xml socket server, 
whereas xmlrpc is for Post operations.  XMLSocket servers can push data 
to a flash client, whereas xmlrpc, in general applied use, cannot 
(although the xmlrpc spec is so good, and so simple, it has been used 
as the basis for some persistent connections).
XMLSocket servers, based on their continious connection model, are 
incredibly bandwidth consuming- but are a logical choice for Chat/Game 
multi-user applications.

The manner in which these applications use xml data is fundamentally 
different from an xmlrpc communication, (smaller nests of xml data, 
passed back and forth in chunks)- although the data type requirements 
are functionally the same.

If you are interested in XMLSocket servers, Fortress makes a very well 
respected server (uses Java),
http://xadra.com/
and for an Open-Source flash socket server,
http://swocket.sourceforge.net



--
PLEASE NOTE:
If you end up using the xmlrpcflash actionscript library, please be 
aware of the following:

We are currently tearing apart all of the response handling methods, as 
well as re-evaluating the base object handlers- with the aim of having 
a much simpler library for practical use.  Additionally, the Liscense 
is moving from GPL to LGPL, so it's use has little restriction for 
commercial uses.

Keep an ear out for further developments, and if you or your associates 
have time to contribute to the project, (even just critique, 
commentary, feature list...), please join the developers mailing list!

http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development

Best,
Isaac



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

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

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

Wordemup, I'm responding to this sourceforge-discussion posting right 
now, and Ed, I'll get back to your post in about 30 min-

Begin forwarded message:

> From: no...@so...
> Date: Mon Nov 25, 2002  4:25:28 PM America/New_York
> To: no...@so...
> Subject: [xmlrpcflash - Open Discussion] secure functionality with 
> Flash xmlrpc
>
>
> Read and respond to this message at:
> https://sourceforge.net/forum/message.php?msg_id=1770220
> By: nobody
>
>
> Dear all,
>
> we are developing the server side of an xmlrpc based application.
>
> 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.
>
> 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).
>
> 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.
>
> Two questions:
>
> 1) Is there any way to use HTTP Auth with Flash xmlrpc?
>
> 2) Are SSL connections supported with Flash xmlrpc, or (I guess if it 
> used XMLSockets
> directly or indirectly) will we need to plug in our own MD5.
>
> I would be very grateful if you could cc any responses to 
> m.r...@uc...
>
>
>
>
> ______________________________________________________________________
> You are receiving this email because you elected to monitor this forum.
> To stop monitoring this forum, login to SourceForge and visit:
> https://sourceforge.net/forum/monitor.php?forum_id=78086
>
>

[xmlrpcflash-development] Reporting success

[Ed C. <ed-...@gr...>]

Hey Isaac and everyone else.

I just grabbed the newest code off viewartwork, and tweaked it a bit to
run on my zope.

This is a super simplified test, as there is only one argument, and one
response, but I do have a little project to work on that is really this
simple...

I'm passing one variable "name" off to the server that returns "hello
/name/".  For 7 lines of code, its not too bad...  =)

------------------------- Snip --------------------------

#include "xml-rpc.as"
objXMLRPC = new XMLRPC("http://xml.siegerecords.com/",30);

objtest = new XMLRPC_Object("string");
objtest.AddMember("name");
objtest.SetValue("duh");

objXMLRPC.AddParameter(objtest);
objXMLRPC.Call("xmlrpctest");

---------------------------------------------------------

Now on to play with a little movie that uses it in this simple way...

After that...  I'll need to get multiple return values figured out.

Thanks for all the hard work!

-ed-




-- 
Green Graphics   :::   Print and Web Design   :::   510.923.0000

[xmlrpcflash-development] DocBook Tools?

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

Hello all,

Patrick had mentioned keeping documentation of the xmlrpcflash project 
in DocBook xml format, and I was wondering if there were any sort of 
doc-book authoring tools anybody knows of to easily write DocBook 
formatted documentation? (I'm on MacOSX, but server-based tools would 
serve us all...)

Rocket-
.ike



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

[xmlrpcflash-development] revision files: 0.5r1 and 0.5r2

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

Hello All,

I posted some Revision files on a temporary server (with functioning 
xmlrpc via Zope/Apache2).

The ViewArt network has been gracious enough to loan us some space and 
bandwidth for testing- (as I'm currently working with them [thanks 
Chad!]) but this is by no means a permanent situation.

The files for download are located here:
http://viewartnetwork.com/xmlrpcflash

--
The posted zip archive contains the following pertanent files,
(my apologies for the brown-bag release):

xmlrpc0_5r2.fla
	+connects to the server properly
	+calls a method I wrote which returns
	 an xmlrpc response, going for the
	 functionality of Patrick's original
	 xml test file (*)

whitesp_response.xml
	+just like Patrick's response.xml file, but
	 testing real-world whitespace in the xml.
	 (Patrick's code seems to do just fine with it)


--
(*)ikenote regarding the 'test_response' method:
	This method is meant to mimmic the resoponse xml which
	came with Patrick's xmlrpcflash 0.5 Alpha.  This method
	is currently a work in progress, as I have not taken time
	to deal with these 3 object types:
		DateTime, Boolean, and Base64 Binaries
	as well as return multiple <param> values.

--
Additionally, I have applied the xmlrpc logo, and made a space where we 
can hopefully put some traceback actions as we are working.

--
--

Who is doing what:
This file has been verbally handed off to my Colleauge, actionscript 
rockstar, Chad, (who's now on this list), for evaluation and jamming 
into suggestions parsing the xml response in a sensible manner- and I'm 
availible for server support and xmlrpc protocall questions.

Chad- please post any questions/comments regarding this file to the 
list- and also note, that for the xml parsing, the server need not be 
necessarily used (especially as my method there isn't really complete)- 
the 'whitesp_response.xml' file will load for parsing just fine.

OK- Rocket-
.ike



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

Re: [xmlrpcflash-development] Greetings!

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

Hi Ed,


On Wednesday, November 20, 2002, at 02:57 AM, Ed Colmar wrote:

> Hi Isaac
>
> Ok, I'll toss that old one, and maybe start playing around with the old
> alpha again.
>
> Was there another piece to this code that was never released?  Could we
> get a copy of that passed around so we're all on the same page?
>
> Looking forward to cranking on this.
>
> -ed-
>

OK- here's the dealio-
I'm re-posting this from an email I started out the mailing list with, 
and I don't think you were subscribed at that point.

The following code is all there is right now in lieu of staying on the 
same page, and the stuff I passed around before, should for all 
practical purposes, be discarded for now.

I hope this helps-
I'll be on the wire working on xmlrpcflash lib throughout this 
afternoon and evening-
Rocket-
.ike

Begin forwarded message:

> From: Isaac Levy <ik...@vi...>
> Date: Tue Nov 5, 2002  5:47:54 PM America/New_York
> To: xml...@li...
> Subject: [xmlrpcflash-development] Patrick's patch code for the 
> response parse bug
> Reply-To: xml...@li...
>
> Just thought I'd post this code here, for the record-
> It is a Patch for the 0.5 Alpha release:
>
>> On Tuesday, October 8, 2002, at 09:32 PM, Patrick O'Lone wrote:
>>
>>>
>>> Actually, the unreleased API simply abstracts more from the
>>> implementor by
>>> auto-calling most methods implicitly. In addition, some clarification
>>> of the
>>> types created and bug fixes were implemented. But now that I've heard
>>> more
>>> about your woes with the engine's getResults() method, I'm wondering
>>> if the
>>> best solution is to simply force the developer to implement 
>>> callbacks.
>>> The
>>> idea would be something like this:
>>>
>>> EchoClient.prototype.__proto__ = XMLRPC.prototype;
>>> EchoClient.prototype.startElement() = function ( name, attrs ) {
>>>
>>>    // Handle structs how I see fit
>>>
>>> }
>>>
>>> EchoClient.prototype.endElement() = function ( name ) {
>>>
>>>   // Handle array elements how I see fit
>>>
>>> }
>>>
>>> EchoClient.prototype.dataElement() = function ( data ) {
>>>
>>>   // Deal with data elements
>>>
>>> }
>>>
>>> objEchoClient = new EchoClient();
>>>
>>> Perhaps, the XMLRPC object would simply call these methods of itself,
>>> with
>>> the assumption the developer is to implement these by inheriting the
>>> XMLRPC
>>> class and defining these methods, then instantiate that object to
>>> process
>>> the XML-RPC message. The object would still call getResults(), but 
>>> the
>>> method would now run parse() and call the subclass's overloaded 
>>> methods
>>> instead (we'd set defaults for debug purposes).
>>>
>
> A sample rework of Parse() (it's MUCH simpler IMHO) would be:
>
> function Parse ( Node )
> {
>     if (Node.nodeType == 3) {
>
>        // Data elements call the dataElement() method as overloaded
>        // by the inherited class.
>
>        this.dataElement(Node.nodeValue);
>
>     } else if (Node.nodeType == 1) {
>
>        // Tag elements call startElement() first, and pass any 
> attributes
>        // that exist to that method as well.
>
>        this.startElement(Node.nodeName, Node.attributes);
>        for (var i in Node.childNodes) {
>
>            // Parse each child node that this node has.
>
>            this.Parse(Node.childNodes[i]);
>
>        }
>
>        // End this element by calling the overloaded endElement() 
> method
>
>        this.endElement(Node.nodeName);
>
>     } else {
>
>        // Something has gone terribly wrong - this isn't
>        // a possible state!
>
>        return false;
>
>     }
>
>     return true;
>
> }
>
> Regards,
>
> -----------------------------------------
>
> Patrick O'Lone
> Aeon Solutions, Inc.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm Tungsten T 
> handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> /*==============================================================
>  xmlrpcflash-development mailing list
>  xml...@li...
>  http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>  ==============================================================*/
>
>

Re: [xmlrpcflash-development] Greetings!

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

Hi Ed,
Sorry for the email confusion.

On Friday, November 15, 2002, at 10:31 PM, Ed Colmar wrote:

> Hmmm...  This was a private mail...
>
> You said it was as far as you had gotten, but were considering 
> reworking
> it...

Right- OK- that file.

That one I'd tried to implement the XMLNitro code for parsing the xml, 
in an attempt to parse the xml returned faster, simpler, and cleaner.
To be honest, I don't think it was a good implimentation- here's why:
It seems to me, (and after some of Patrick's good critique) that I was 
really just me coding blindly- and not doing any planning.  I was 
attempting to deal with the results of the xmlrpc call (which wasn't 
working very well).

In the original code, (the Alpha which is online now), the Array object 
which is returned, I and some flash folks here had trouble using the 
results.

So, I (a bit blindly), set out to write a better parser, came across 
XMLNitro, and then Max Ziebel's XMLarray actionscript.
I implimented it, and while it does return results from the xmlrpc 
response, it doesn't take into account any good structure for their 
return.

In the end, I wouldn't go too far with that code.  I'm not sure where 
Patrick is at, but I'm mapping out the current Actionscript, and 
comparing it to the goals and processes outlined in the xmlrpc 
specification- to see where to code next.

>
> Was this in a working state?
>
> Sorry for the confusion  =)
>
> -e-

I hope that wasn't confusing, and also i'm sorry to take the weekend to 
get back to you, been swamped with work lately so I've been shutting 
down my brain on weekends.

OK, with that for now,
Rocket-
.ike

Re: [xmlrpcflash-development] Greetings!

[Ed C. <ed-...@gr...>]

Hmmm...  This was a private mail...

You said it was as far as you had gotten, but were considering reworking
it...

Was this in a working state?

Sorry for the confusion  =)

-e-

On Sat, 9 Nov 2002, Isaac Levy wrote:

> Hi Ed!
>
> Which do you mean?
>
> On Friday, November 8, 2002, at 02:36 AM, Ed Colmar wrote:
>
> > I got your latest source Isaac.  Do you have a quick example of it in
> > use
> > just so I can start to grok the syntax?
>
> I haven't really released any code-(?)- which code do you mean?
>
> Rocket-
> .ike
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> //
> //  xmlrpcflash-development mailing list
> //  xml...@li...
> //  http://lists.sourceforge.net/lists/listinfo/xmlrpcflash-development
>
>

-- 
Green Graphics   :::   Print and Web Design   :::   510.923.0000

Re: [xmlrpcflash-development] Greetings!

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

Hi Ed!

Which do you mean?

On Friday, November 8, 2002, at 02:36 AM, Ed Colmar wrote:

> I got your latest source Isaac.  Do you have a quick example of it in 
> use
> just so I can start to grok the syntax?

I haven't really released any code-(?)- which code do you mean?

Rocket-
.ike