SWFUpload Word of warning

[Ian Boston]

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