SWFUpload Word of warning
ieb at tfd.co.uk
Fri Mar 7 14:40:10 UTC 2008
The guys at Caret have done some further investigation and discovered
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.
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://
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
If this post is not of relevance to fluid and I should post it
somewhere else, please just say.
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
> 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 ?
More information about the fluid-work