Firefox 2.0.0.5

Thanks LTG,

So considering that the Asp.net form authentication is using httponly cookies then it looks like I am concerned ? Right ?

That also means almost all the asp.net website won't work since most of them authenticate users...

But I don't see why Aurigma would be concerned by this httponly cookie ? What does form authentication has to do with image uploader ?

The httponly evolution implemented in 2.0.0.5 prevents from reading a cookie through javascript. I am not trying to read that cookie, and I don't see why Image upload would.

I have also set the page directives enablesessionstate to false but still no luck. Is it what franckly means when he says he changed the security settings and it worked ?

Tx

Thank you very much Andrew for you explanations of the mechanism that I didn't really know.

I know this is an old post that shouln't be related to the new firefox but I am curious to have a feedback from ASP.NETusers using form authentication since it looks like a way to bypass the problem:

http://www.aurigma.com/Forums/Topic4989-12-1.aspx

Chris3e mentions a problem with the form authentication which prevents from connecting, and here is his solution:

"Found the problem. I had to change a property of the forms authentication which allows/prevents the cookie being sent/received as part of the request object."

Wouldn't it be the solution, not to send this form authentication cookie ?

The only problem is that I can't find what he did. I don't see any property doing that. Any idea ?

Thanks

Hello,

We've made a sample to check out this solution with HttpOnly == false and it works.
See the attachment to this message - there is a zip-archive with the asp.net project, that shows this work-around (you should place there .cab and .jar files).

I still can't have a look at your test unfortunately, but I guess it's no longer useful.

My work-around works, so does your test, but only in some cases and there is still an issue with your java code.

The HttpOnly set to false really works, and I was wondering why not in my case. I am actually using roles, and my upload pages are in specific folders reserved for logged members.

So I suspected that the processing page would be rejected because of a temporary loss of connection.

To make sure I moved the page to the root, without any risk of denial if not connected.

I can now see that I can reach that page while uploading, and confirm why I get rejected : I am not authenticated.

So any attempt in my code-behind to get a member id gives an error.

This is the case under FF, but not at all under IE where I keep my authentication.

The cookie is not deleted since I am still authenticated afterwards, but for some reason it may not be readable maybe.

Any idea ?

Thanks.

The HttpOnly==false works fine.

Everything I read about the HttpOnly set to true was saying that anyway it doesn't really protect from any cookie stealing. So I would say that in terms of security it doesn't seem to be a big deal.

The only, and major for me, issue is what I just explained in my previous post. If your processing page is in a protected folder or requires information about the connected member then you'll be rejected.

Hello,
Imm glad to hear that there is communication going on about this issue. I've posted my issue before, and it may be related, but I'm not sure. To recap:

I was integrating the uploader about 2 months ago and everything was working fine. I left it, and came back to it about a month later. The uploader no longer initializes. This was occured on a Windows Pro Machine w FF 2.0.0.6 as well as a Vista W/ FF 2.0.0.6. When I use IE the ActiveX is fine. When I deactivate the ActiveX portion and use solely Java, it doesn't initialize.

I keep the .jar file in the same directory as my code and use this code to call it.

//For Java applet we specify only directory with JAR files
iu.javaAppletCodeBase = "./";
iu.javaAppletCached = false;
iu.javaAppletVersion = "2.5.35.0";

so I don't believe it's because it can't find the jar file.

I know it sounds weird, but what I believe is that if the *server* that is hosting the file has FF > 2.0.0.5, and the Uploader is in a directory that requires sessions than the initialization will fail. As if FF does something to the actual OS.

At one point I had a Windows Pro machine for local development that had 2.0.0.4 and it was working fine - I was using it to debug the initialization error. Once I upgraded to FF 2.0.0.6, I can no longer initialize the uploader in a secure directory. However, when I move the files over to another directory, one that does not require authentication, then the uploader initializes fine.

I currently have the code on a Windows Server 2003 w/ FF 2.0.0.3, inside a directory that requires authentication/session and it's working fine w/ different types of browsers. It's the exact code as on my local development machines.

Is this a related issue? Any insight? Should I submit another ticket? Thank you in advance.

Here's all the JS code I use to initialize the uploader. I believe I copied and paste from a sample to ensure I had one that worked.


var iu = new ImageUploaderWriter("ImageUploader", 770, 500);
iu.activeXControlEnabled = true;
iu.javaAppletEnabled = true;

//For ActiveX control we specify full path for CAB file
iu.activeXControlCodeBase = "./ImageUploader4.cab";
iu.activeXControlVersion = "4,5,35,0";
iu.activeXControlEnabled = false;
//For Java applet we specify only directory with JAR files
iu.javaAppletCodeBase = "./";
iu.javaAppletCached = false;
iu.javaAppletVersion = "2.5.35.0";

iu.showNonemptyResponse = "off";

//appearance & behaviour
iu.addParam("AllowRotate", "false");
iu.addParam("BackgroundColor", "#ffffff");
iu.addParam("DropFilesHereText", "Drop images here");
iu.addParam("FileMask", "*.jpg;*.jpe;*.gif");
iu.addParam("FolderPaneHeight", "300");
iu.addParam("PaneLayout", "ThreePanes");
iu.addParam("ShowDebugWindow", "true");
iu.addParam("ShowDescriptions", "false");
iu.addParam("PreviewThumbnailSize", "70");
//iu.addParam("ThumbnailVerticalSpacing", "5");
iu.addParam("UploadView", "Details");

//Configure upload settings.
iu.addParam("AutoRecoverMaxTriesCount", "3");
iu.addParam("AutoRecoverTimeOut", "10000");
iu.addParam("FilesPerOnePackageCount", "1");

//Configure URL files are uploaded to.
iu.addParam("Action", "imageuploadprocess.aspx");
iu.writeHtml();

workaround:

step 1. change the HttpOnly attribute of the FormsAuth cookies and ASP.NET_SessionId cookies:
http://support.microsoft.com/kb/917412/en-us
you can see this two cookies via firefox'menu --> tools --> options --> privacy --> show cookies --> your website location

step 2. aurigma image uploader can now access the SessionId cookies, but it still cannot see the
FormsAuth cookies :angry: . can anybody tell me why ?
you can check this from the java-console: firefox's menu --> tools --> java console

step 3. so we need to move the page which images are sent to from the FormsAuth protection to a public location, because the image uploader can not send the FormsAuth cookies back to it correctly.
in configuration section of the web.confing, we add:








step 4. if you think step3 is not safe, you can check some session data such as Session["USERNAME"] in Page_Load(), since aurigma image uploader can send the sessionid cookies back correctly.
if ( Session["USERNAME"] == null ) {
Response.Redirect("Login.aspx",true);
}

You can use a recipe for disabling http-only cookies from far41’s link

http://support.microsoft.com/kb/917412/en-us