Flash based FileUpload asks for login, tomcat, richfaces

Jan 27, 2011 at 3:51 PM
I can get the user name using negotiate - works well.
If I use RF FileUpload without flash waffle still works.
If I enable flash on the FileUpload component IE8 shoes the login dialog upon uploading the file.
Any ideas how to stop this behavior?
  • Windows Server 2008
  • Tomcat 6 or 7
  • JSF 2.0 w/ facelets
  • Richfaces 3.3.3
  • Client is Windows XP
  • Testing on localhost
Coordinator
Jan 27, 2011 at 6:11 PM

It's probably using a different verb than POST, but might behave as one. Get an IEHttpHeaders trace. Once you figured out which exact request fails on the server, it's either a question of configuration or a trivial code change in Waffle.

Jan 27, 2011 at 7:44 PM

I see a difference in Accept and User Agent.

This fails:

POST /salesgoals/index.xhtml;jsessionid=C5CE96E44CD369404269664631DE68A6?_richfaces_upload_uid=0.09614133438007871&form1: upload=form1:upload&_richfaces_upload_file_indicator=true&_richfaces_size=9973&_richfaces_send_http_error=true HTTP/1.1Accept: text/*Content-Type: multipart/form-data; boundary=----------Ij5cH2cH2cH2ae0GI3Ij5KM7Ef1Ef1User-Agent: Shockwave FlashHost: localhostConnection: Keep-AliveCache-Control: no-cacheCookie: JSESSIONID=C5CE96E44CD369404269664631DE68A6Authorization: Negotiate TlRMTVNTUAABAAAAB7IIog0ADQAzAAAACwALACgAAAAFASgKAAAAD1VTRkxEU0s3MDMyV0FUU09OX0RPTUFJTg==Content-Length: 0

This works:

POST /salesgoals/index.xhtml?_richfaces_upload_uid=0.11617270503291815&form1: upload=form1:upload&_richfaces_upload_file_indicator=true&AJAXREQUEST=j_id10 HTTP/1.1Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-shockwave-flash, */*Referer: http://localhost/salesgoals/Accept-Language: en-usUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)Content-Type: multipart/form-data; boundary=---------------------------7db1427e069eAccept-Encoding: gzip, deflateHost: localhostContent-Length: 0Connection: Keep-AliveCache-Control: no-cacheCookie: JSESSIONID=9F2AA67A24F93CDA4877EF6BB9063ED9Authorization: Negotiate TlRMTVNTUAABAAAAB7IIog0ADQAzAAAACwALACgAAAAFASgKAAAAD1VTRkxEU0s3MDMyV0FUU09OX0RPTUFJTg==

Coordinator
Jan 27, 2011 at 7:46 PM
Edited Jan 27, 2011 at 7:48 PM

Post the entire HTTP failing conversation. What does the server reply with for the failing one?

Coordinator
Jan 27, 2011 at 7:47 PM

Also, this article will explain why there's a re-authentication. But it doesn't explain why it doesn't work.

Coordinator
Jan 27, 2011 at 7:50 PM

After googling around, I think I know what's going on. I bet the flash client doesn't know how to handle NTLM. You would see a 401 response from the server and the client never sends anything back popping up a message. This page talks about an update that should fix it.

Jan 27, 2011 at 7:54 PM

This is the entire conversation. I clicked cancel on the login dialog:

POST /salesgoals/upload.xhtml;jsessionid=9F2AA67A24F93CDA4877EF6BB9063ED9?_richfaces_upload_uid=0.007542548085323175&form1: upload=form1:upload&_richfaces_upload_file_indicator=true&_richfaces_size=9973&_richfaces_send_http_error=true HTTP/1.1Accept: text/*Content-Type: multipart/form-data; boundary=----------Ef1ei4gL6GI3Ef1ae0ae0KM7KM7cH2User-Agent: Shockwave FlashHost: localhostConnection: Keep-AliveCache-Control: no-cacheCookie: JSESSIONID=9F2AA67A24F93CDA4877EF6BB9063ED9Authorization: Negotiate TlRMTVNTUAABAAAAB7IIog0ADQAzAAAACwALACgAAAAFASgKAAAAD1VTRkxEU0s3MDMyV0FUU09OX0RPTUFJTg==Content-Length: 0
HTTP/1.1 401 UnauthorizedServer: Apache-Coyote/1.1WWW-Authenticate: Negotiate TlRMTVNTUAACAAAAGgAaADgAAAAFwomijSWQHSVttOYo1hQAAAAAAKgAqABSAAAABQEoCgAAAA9XAEEAVABTAE8ATgBfAEQATwBNAEEASQBOAAIAGgBXAEEAVABTAE8ATgBfAEQATwBNAEEASQBOAAEAFgBVAFMARgBMAEQAUwBLADcAMAAzADIABAAaAG4AYQAuAHcAYQB0AHMAbwBuAC4AYwBvAG0AAwAyAFUAUwBGAEwARABTAEsANwAwADMAMgAuAG4AYQAuAHcAYQB0AHMAbwBuAC4AYwBvAG0ABQAUAHcAYQB0AHMAbwBuAC4AYwBvAG0AAAAAAA==Connection: keep-aliveContent-Type: text/html;charset=utf-8Transfer-Encoding: chunkedVary: Accept-EncodingDate: Thu, 27 Jan 2011 20:53:36 GMT
GET /salesgoals/a4j/g/3_3_3.Finalorg/richfaces/renderkit/html/images/ico_add.gif.xhtml HTTP/1.1Accept: */*Referer: http://localhost/salesgoals/upload.xhtmlAccept-Language: en-usUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6.6; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; FDM; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)Accept-Encoding: gzip, deflateIf-Modified-Since: Thu, 27 Jan 2011 20:29:12 GMTHost: localhostConnection: Keep-AliveCookie: JSESSIONID=9F2AA67A24F93CDA4877EF6BB9063ED9
HTTP/1.1 304 Not ModifiedServer: Apache-Coyote/1.1Pragma: No-cacheCache-Control: no-cacheExpires: Wed, 31 Dec 1969 19:00:00 ESTDate: Thu, 27 Jan 2011 20:53:40 GMT

 

Coordinator
Jan 27, 2011 at 7:56 PM

Yep, your rich-faces client doesn't know how to deal with NTLM (multi-step authentication). It never sends back an Authorization: NTLM ticket the second time around. Talk to the people making the plugin.

Jan 27, 2011 at 8:00 PM

Thank you dblock. You put the puzzle together for me. I'll post at RichFaces and see what happens.

Jan 27, 2011 at 10:41 PM

I think you'll have the same issue with any of the SWF file uploaders.  I'm using Uploadify and I get a challenge too.

GET /uploadify/cancel.png HTTP/1.1Accept: */*Referer: http://localhost:8080/afe/afe_attachments.jspAccept-Language: en-usUA-CPU: x86Accept-Encoding: gzip, deflateIf-Modified-Since: Thu, 27 Jan 2011 21:29:15 GMTIf-None-Match: W/"2960-1296163755209"User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8)Host: localhost:8080Connection: Keep-AliveCookie: JSESSIONID=CCF96733E4E78A793ED4C49CF4A5DBD0

HTTP/1.1 304 Not ModifiedServer: Apache-Coyote/1.1X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1ETag: W/"2960-1296163755209"Date: Thu, 27 Jan 2011 23:36:16 GMT

POST /UploadServlet?test=1234 HTTP/1.1Accept: text/*Content-Type: multipart/form-data; boundary=----------gL6cH2cH2cH2ei4Ij5ae0gL6KM7KM7User-Agent: Shockwave FlashHost: localhost:8080Connection: Keep-AliveCache-Control: no-cacheCookie: JSESSIONID=CCF96733E4E78A793ED4C49CF4A5DBD0Authorization: Negotiate TlRMTVNTUAABAAAAB7IIoggACAA1AAAADQANACgAAAAFASgKAAAAD0NUVUxUNjAwMDQ1NTNXSUxMSUFNUw==Content-Length: 0

HTTP/1.1 401 UnauthorizedServer: Apache-Coyote/1.1X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1WWW-Authenticate: Negotiate TlRMTVNTUAACAAAAEAAQADgAAAAFwomi1KFYVuJKSSuASigBAAAAAKYApgBIAAAABQEoCgAAAA9XAEkATABMAEkAQQBNAFMAAgAQAFcASQBMAEwASQBBAE0AUwABABoAQwBUAFUATABUADYAMAAwADAANAA1ADUAMwAEABgAVwBJAEwATABJAEEATQBTAC4AQwBPAE0AAwA0AEMAVABVAEwAVAA2ADAAMAAwADQANQA1ADMALgBXAEkATABMAEkAQQBNAFMALgBDAE8ATQAFABgAVwBJAEwATABJAEEATQBTAC4AQwBPAE0AAAAAAA==Connection: keep-aliveTransfer-Encoding: chunkedDate: Thu, 27 Jan 2011 23:36:18 GMT

 

Is there anyway around this?  Again, I'm just using the user that I get from the filter and don't need NTLM authentication to occur on all pages, but I can't find a way to solve this.

 

Jan 28, 2011 at 11:25 AM

After more research I conclude it is indeed Flash causing this issue.

It seems Flash is responsible for sending the headers and it doesn't send all the headers the browser alone would.

Maybe we could build some kind of filter to append the missing headers coming from the SWF object. Althought I don’t have the skills to do that.

 

Coordinator
Jan 28, 2011 at 12:53 PM

I think that you have to either get an upload component that supports NTLM or remove protection from the upload URL (split the site in two). The latter might not be that bad because one of the issues is about how NTLM works. NTLM is a connection-oriented protocol, you need to re-authenticate per connection. But Tomcat sessions are per client, so you actually are already logged in securely. If you're protecting everything with NTLM you can't fool the browser not to send a first POST with a Content-length: 0, but if you post to two different destinations it might just work.

Jan 28, 2011 at 4:44 PM

How can I unprotect a single page or folder - upload page?

Or protect a single page or folder - login page?

Coordinator
Jan 28, 2011 at 4:47 PM

You'll have to look at your webserver's docs. This is done via traditional methods in WEB-INF/web.xml.

Jan 28, 2011 at 5:53 PM

I attempted to use two different war deployments within the same application server (JBoss 5).  One deployment is through the filter with NTLM, the other is not.  This doesn't work because both share the same jsessionid and even though the second app is not under authentication, the servlet post gets the content blocked.  Am I doing this wrong?  I'm sure looking for a means to get around this issue.

Jan 28, 2011 at 6:19 PM
I think the solution is either don't use Flash, which is the cause of
the problem or somehow wrap the flash component in a non-flash
component.

If you could wrap flash and grab it's header info, etc, and include it
with a regular post then it should work.

Thing is I have no idea how to do it.
Feb 11, 2011 at 6:25 PM

dbnorris77, have you made any ground on this?  I've just ended up totally frustrated that I can't implement a good multiple file upload as long as I'm using NTLM authentication.