SWFUpload Word of warning

[Eli Cochran]

Ian,
This is all very relevant. And good information.

The SSL stuff is concerning. Some of the research I've done  
indicates... Well, I'll just send the reference:

	http://swfupload.org/forum/generaldiscussion/117

Very common issue dealing with SSL.

I don't completely understand the implications of the cookie bug.

My apologies for not having something running yet that we can really  
test out. Working on that. Should have something up soon... Shooting  
for Monday or Tuesday.

I guess my biggest concern right now is that for good multi-file  
upload we really don't have another option but Flash. Java would be  
OK, except for slow loading times and nasty security warnings. So I'm  
pretty invested in making this work.

But if it's flaky then it's flaky.

I'll read that Adobe thread.

Thanks,
Eli

On Mar 7, 2008, at 6:40 AM, Ian Boston wrote:

> The guys at Caret have done some further investigation and discovered
> this.
>
> http://swfupload.org/forum/generaldiscussion/383
>
> It may be possible to work around the cookie bug, but the long list
> of complaints about flash.net.FileRefernce.upload on the adobe site
> worries me a bit.
>
> http://livedocs.adobe.com/flash/8/main/wwhelp/wwhimpl/common/html/
> wwhelp.htm?context=LiveDocs_Parts&file=00002204.html
>
> Things like,
>  if you give it https://camtools.caret.cam.ac.uk/  it changes the
> url to https://camtools.caret.cam.ac.uk:80/ which is wrong (not SSL).
> You can work around by forcing the URL to  https://
> camtools.caret.cam.ac.uk:443/
>
> Perhaps all of these have been worked around in SWFUpload, but the
> proxy thing is still a worry for me.... since they clearly are not
> using the Browser transport, and that certainly will cause a problem
> in FF which manages its own proxy separate from the OS on most
> platforms.
>
>
> If this post is not of relevance to fluid and I should post it
> somewhere else, please just say.
>
>
> Ian
>
>
>
> On 7 Mar 2008, at 08:52, Ian Boston wrote:
>
>> Word of warning about SWFUpload.
>>
>> I have been doing some tests on Sakai, and on OSX Firefox at least,
>> it does not appear to use the browser http channel.
>>
>> a) No cookies from the browser are coming through on the
>> SWFConnection. (so the connection doesn't appear to be logged in to
>> Sakai)
>> b) Firebug does not show it up on the network activity.
>>
>> If this is true, and the case for all browsers SWFUpload will
>> require that the security and proxy settings are transfered from
>> the browser to SWFUpload before it will work in a secure
>> environment. Transferring cookies is probably built in, but proxy
>> settings may be harder. It may also have problems with client side
>> SSO (eg Kerberos etc)
>>
>> Has anyone else seen this behavior or had to do anything special to
>> make it work with Sakai ?
>>
>> Ian
>>
>>
>>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley