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 [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
