5 Replies Latest reply on Sep 29, 2010 7:33 AM by Prashanthas

    NTLM and FileReference

    AndrewUniqueName
      Hi,

      We are using NTLM authentication with a Flex client. Every thing goes okay, the calls that use HTTPService negotiate the exchanges (via Internet Explorer) fine, e.g. here is a snippet of a successful exchange:


      REQUEST ----------------------------->
      GET /dso/session.htm HTTP/1.1
      Accept: */*
      Accept-Language: en-AU
      Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
      x-flash-version: 9,0,124,0
      Accept-Encoding: gzip, deflate
      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M+T6bxhicNRVal/wgDj6Jmx4bCRU0zRaOWUffdI6 i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
      Host: 127.0.0.1:8888
      Connection: Keep-Alive

      RESPONSE ----------------------------->
      HTTP/1.1 401 Unauthorized
      Server: Apache-Coyote/1.1
      Set-Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5; Path=/dso
      WWW-Authenticate: NTLM
      Connection: Keep-Alive
      Content-Length: 0
      Date: Tue, 11 Nov 2008 00:24:04 GMT

      REQUEST ----------------------------->
      GET /dso/session.htm HTTP/1.1
      Accept: */*
      Accept-Language: en-AU
      Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
      x-flash-version: 9,0,124,0
      Accept-Encoding: gzip, deflate
      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M+T6bxhicNRVal/wgDj6Jmx4bCRU0zRaOWUffdI6 i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
      Host: localhost:8888
      Connection: Keep-Alive
      Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
      Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAwAAAACAAIACgAAAAFASgKAAAAD0c4MTAwNzAzSU5URVJOQUx=

      RESPONSE ----------------------------->
      HTTP/1.1 401 Unauthorized
      Server: Apache-Coyote/1.1
      WWW-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADAAAAAFAoEAfyr4iuLClfwAAAAAAAAAADYANgBAAAAASQBOAFQARQBSAE4AQQBMAAIAE ABJAE4AVABFAFIATgBBAEwAAQAaAEoAQwBJAEYAUwA5AF8AMQA0ADkAXwA4AEUAAAAAAA==
      Connection: Keep-Alive
      Content-Length: 0
      Date: Tue, 11 Nov 2008 00:24:04 GMT

      REQUEST ----------------------------->
      GET /dso/session.htm HTTP/1.1
      Accept: */*
      Accept-Language: en-AU
      Referer: file://D:\apatterson_DSO_msrmt_dev\DSO\flex\bin-debug\main.swf
      x-flash-version: 9,0,124,0
      Accept-Encoding: gzip, deflate
      User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; CK={kNtZyDfw/DaG7tc4kqJoqg4o4RsAvrp/4KYm8HzTMOXn3M+T6bxhicNRVal/wgDj6Jmx4bCRU0zRaOWUffdI6 i/L7gSNHG1Qo4JawEfjO2k=}; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
      Host: localhost:8888
      Connection: Keep-Alive
      Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHwAAAAYABgAlAAAABAAEABIAAAAFAAUAFgAAAAQABAAbAAAAAAAAACsAAAABQKAAgUBK AoAAAAPSQBOAFQARQBSAE4AQQBMAEEAUABhAHQAdABlAHIAcwBvAG4ARwA4ADEAMAAwADcAMAAzAPVsPO48S8VWr7P AUZJBy9//U4KoBUTj0nOKpwnje0pQ9K4FZP6ClW3pKFChYcHFEw==
      Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5

      RESPONSE ----------------------------->
      HTTP/1.1 200 OK
      Server: Apache-Coyote/1.1
      Content-Type: text/html;charset=ISO-8859-1
      Content-Language: en-AU
      Content-Length: 38
      Date: Tue, 11 Nov 2008 00:24:06 GMT

      Which is great. But when we try to use the File reference class we run into the IE Post optimisation problem where:
      quote:


      See http://lists.samba.org/archive/jcifs/2006-September/006554.html for the full message.
      Microsoft has implemented a performance
      enhancement in IE which prevents IE from sending any POST data to a server
      once NTLM has been negotiated with that server. This was done because IE is
      assuming that the server will require the browser to re-negotiate NTLM for
      the POST request. IE is preemptively assuming that the response from the
      server will be a HTTP 401 response and that the server will do no processing
      on the request. It therefore does not waste the bandwidth to supply all of
      the POST data in the initial request which is sent with the NTLM type 1
      message. (This could be considerable savings depending on the actual size
      of the POST data.) Once the server rejects the initial POST request from
      the browser and responds with the NTLM type 2 message, the browser will
      issue a second request containing the NTLM type 3 message along with the
      desired POST data.



      So basically the same negotiatation should happen, except that part of the negotiation is pre-empted by the Flash/IE and the exchange starts with an empty POST and a type 1 NTLM handshaking message... which is what does happen... however once the server replies with a proper type 2 NTLM message Flash/IE doesn't send any reply... (see the exhange below):

      POST /dso/uploadFile.htm;jsessionid=4558DD04E3389077D5679EC4F921CEC5 HTTP/1.1
      Accept: text/*
      Content-Type: multipart/form-data; boundary=----------Ij5cH2cH2GI3Ef1KM7Ef1gL6gL6cH2
      User-Agent: Shockwave Flash
      Host: localhost:8888
      Connection: Keep-Alive
      Cache-Control: no-cache
      Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
      Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAwAAAACAAIACgAAAAFASgKAAAAD0c4MTAwNzAzSU5URVJOQUw=
      Content-Length: 0

      HTTP/1.1 401 Unauthorized
      Server: Apache-Coyote/1.1
      WWW-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADAAAAAFAoEA6nBCzTE+sXIAAAAAAAAAADYANgBAAAAASQBOAFQARQBSAE4AQQBMAAIAE ABJAE4AVABFAFIATgBBAEwAAQAaAEoAQwBJAEYAUwA5AF8AMQA0ADkAXwA4AEUAAAAAAA==
      Connection: Keep-Alive
      Set-Cookie: JSESSIONID=4558DD04E3389077D5679EC4F921CEC5
      Content-Length: 0
      Date: Tue, 11 Nov 2008 00:24:21 GMT


      So the question is why does FileReference behave in this way while HTTPService is fine?