Welcome Guest! You need to login or register to make posts.

Notification

Icon
Error

2 Pages<12
Options
Go to last post Go to first unread
far41  
#21 Posted : Friday, August 10, 2007 1:32:59 AM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

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



Andrew  
#22 Posted : Friday, August 10, 2007 3:38:36 PM(UTC)
Andrew

Rank: Advanced Member

Groups: Member, Administration
Joined: 8/2/2003(UTC)
Posts: 876

Thanks: 2 times
Was thanked: 27 time(s) in 27 post(s)
Hello Far,

Here is my vision of this problem. When Image Uploader sends a POST request to the server, it constructs it from the scratch. It adds all files and variables, appends additional form (if necessary), and then enumerates all cookies and add them to the request. It uses the same mechanism as you do through JavaScript.

When you send a POST request through the browser it works slightly differently. It does not create blank request. It copies all necessary data from the header of request which the browser receives when the page is loaded. That's why it is able to send back some data which is not available through JavaScript (and hence to Image Uploader).

Currently we are researching whether it is possible to access the page header through Java runtime bypassing DOM. If it is possible, we will be able to send all data in the same manner as the browser does. If not, it means that Image Uploader cannot handle sessions anymore (at least with Firefox). In this case you should use some alternative means to store some variables - like additional form, etc.

Hopefully it shed some light.
far41  
#23 Posted : Friday, August 10, 2007 6:00:18 PM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

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

far41  
#24 Posted : Sunday, August 12, 2007 4:44:54 AM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

The problem is normally coming from the fact that under asp.net 2.0 the form authentication cookies are HttpOnly.

It's actually possible to set up this cookie with httponly set to false. This has to be done under global.asax's session start.

That's what I did.

To make sure it worked, I tested it with a javascript function: I just have one cookie (ASPNET_SessionId) and I can read it (meaning it's no longer HttpOnly) so I guess Image Uploader should be able to.

I have no other cookie except that one.

So it should work, right ?

Unfortunately not. Still the message "waiting for a retry" message.

I still can't access the processing page.

So is the problem really coming from that HttpOnly cookie ??? I don't think so now.

Any explanation ?

Thanks
George Ulyanov  
#25 Posted : Sunday, August 12, 2007 7:49:08 PM(UTC)
George Ulyanov

Rank: Advanced Member

Groups: Administration
Joined: 7/26/2006(UTC)
Posts: 203

Quote:
far41 (8/12/2007)
...So is the problem really coming from that HttpOnly cookie ??? I don't think so now...


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).
File Attachment(s):
TestCase.zip (35kb) downloaded 82 time(s).
Best regards,
George Ulyanov
far41  
#26 Posted : Sunday, August 12, 2007 8:45:12 PM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

Thanks for trying.

But I can't unzip your file (nothing in it apparently).

Thanks
far41  
#27 Posted : Monday, August 13, 2007 1:03:56 AM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

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.
veji  
#28 Posted : Monday, August 13, 2007 1:13:49 AM(UTC)
veji

Rank: Member

Groups: Member
Joined: 8/8/2007(UTC)
Posts: 2

So should we be using the "HttpOnly = false" method as a workaround? Is there any adverse effect or negative consequences to this solution?
far41  
#29 Posted : Monday, August 13, 2007 1:21:02 AM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

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.

far41  
#30 Posted : Monday, August 13, 2007 1:23:52 AM(UTC)
far41

Rank: Advanced Member

Groups: Member
Joined: 10/26/2006(UTC)
Posts: 30

I think you'll like that link:

http://support.microsoft.com/kb/917412/en-us
fodaley  
#31 Posted : Monday, August 13, 2007 4:24:47 AM(UTC)
fodaley

Rank: Member

Groups: Member
Joined: 8/1/2007(UTC)
Posts: 10

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();

fodaley  
#32 Posted : Monday, August 13, 2007 4:17:31 PM(UTC)
fodaley

Rank: Member

Groups: Member
Joined: 8/1/2007(UTC)
Posts: 10

Solved the issue. It seems that the .jar file and the action file needs to be outside the secure directory as well - or else it just screws up your world. Followed the solution in this forum and things are working again.
yuejw  
#33 Posted : Tuesday, August 14, 2007 7:19:52 PM(UTC)
yuejw

Rank: Member

Groups: Member
Joined: 8/14/2007(UTC)
Posts: 1

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);
}

stevewood  
#34 Posted : Wednesday, February 20, 2008 2:45:22 PM(UTC)
stevewood

Rank: Member

Groups: Member
Joined: 12/17/2007(UTC)
Posts: 21

So how does one disable HTTP-Only cookies?

BTW, I see you can add HTTP-Only cookie support to Firefox at this url https://addons.mozilla.o...n-US/firefox/addon/3629.

Eugene Kosmin  
#35 Posted : Wednesday, February 20, 2008 4:15:14 PM(UTC)
Eugene Kosmin

Rank: Advanced Member

Groups: Member, Administration, Moderator
Joined: 9/19/2006(UTC)
Posts: 476

Was thanked: 30 time(s) in 30 post(s)
You can use a recipe for disabling http-only cookies from far41’s link

http://support.microsoft.com/kb/917412/en-us
Best regards,
Eugene Kosmin
The Aurigma Development Team
Users browsing this topic
2 Pages<12
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.