SWFUpload Word of warning

Ian Boston ieb at tfd.co.uk
Fri Mar 7 17:14:38 UTC 2008


Partial Solution,

if the sakai session is appended to the upload url, the session will  
get associated with the request. The Flash Client  (9 on OSX) does  
not accept cookies so they will not leak out to other browsers  
running on the box. However the connection is clearly not owned by  
the browser, the user agent is wrong and there are other  
differences.  I am going to check if this works with a proxy.


Ian



On 7 Mar 2008, at 14:40, 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
>>
>>
>>
>




More information about the fluid-work mailing list