Loading ...
Sorry, an error occurred while loading the content.

Re: Apache-AuthenNTLM-2.07 and ModPerl 1.99_16

Expand Messages
  • Frank Carnovale
    regards the above previous thread ( msg 06315 ) and Chris Hughe s correction ( msg 06333 ).. I also developed a similar fix, mine is too complicated because I
    Message 1 of 8 , Oct 27, 2004
    • 0 Attachment
      regards the above previous thread ( msg 06315 ) and Chris Hughe's correction ( msg 06333 )..
      I also developed a similar fix, mine is too complicated because I note from Chris Hughes' patch that it was unnecessary to instantiate a new Table object when writing into the Notes area.  Also, Chris writes a constant into there rather than a connection-specific value, this is also cleaner and made me realise that the only point of doing this is to flag that the authentication has been done for the given connection.
      The only remaining reason I'm posting this patch is because on running diagnostics during the NTLM msg1,2,3 handshake I also noted that the 'unicode' flag was getting forgotten by this technique under certain flood conditions.  Why this hasn't hit others I don't know, but I suggest that if you are running this module and it is breaking during the NTLM handshake for busy web pages doing lots of GETs, it's because it keeps forgetting to un-unicode the incoming msg data during the handshake.
      This in turn made me realise that the "cache" value, a package-level global, is in theory an inadequate place to remember things like the accept_unicode setting.  It should really be keeping a pool of this (and any other?) state setting for each of the last say, 100 known connections, and cancelling the authenicated-ok state for each least recently used connection that gets bumped out of the pool.  As of the below fix,  we are kind of making it follow the order of msg1 requests completely independently to the order of msg2/3 requests.  Our trace shows that these handshakes are completely out of whack with eachother.
      Our user base is all IE6, and it seems to send msg1s that request 'accept_unicode' always, so we could also get away with just forcing this flag; I wonder when and what browsers negotiate NTLM yet behave differently here anyway.
      .. Frank Carnovale
      <     if (ref ($cache) ne $class || $$conn != $cache -> {connectionid} || $conn -> remote_host ne $cache->{remote_host})
      <         {
      <  $conn -> remote_host ($conn -> remote_host . ' ') ;
      <         $self = {connectionid => $$conn, remote_host => $conn -> remote_host} ;
      <         bless $self, $class ;
      <  $cache = $self ;
      # applying (MP2-only-version-of) patch described in http://www.mail-archive.com/modperl@.../msg06315.html
      # .. and fix it so that it uses an APR::Table object.
      >     # .. fjc and bdn Thu Oct 21 15:04:58 EST
      >     my $notes = $conn->notes || die
      "can't retrieve Apache notes object from connection.\n";
      >     my $notesval =
      $notes->get('AuthenNTLMConnection') || 'some absurd initial value';
      >     if (ref ($cache) ne $class || $$conn !=
      $cache -> {connectionid} || $notesval ne $cache->{notesval}) {
       my $pool = $conn->pool();
      >  my $table =
      APR::Table::make($pool, 1);
      >  $self = bless {}, $class;
       $table->set('AuthenNTLMConnection', "$$ - $self"); # an arbitrary string that only this instance could write
      >  $conn
      >  $self->{connectionid} = $$conn;
       $self->{notesval} = $conn->notes->get('AuthenNTLMConnection');
       $self->{accept_unicode} = $cache->{accept_unicode}; # else gets forgotten during msg1 floods
      >  $cache =

      This email (including any attachments) is intended only to be read
      or used by the addressee. It contains information that may be
      confidential and legally privileged. If you are not the addressee,
      or you have received this email by mistake, you must not disclose,
      copy or distribute it or use the information contained in it (or any
      attachments) in any way.

      If you have received this message in error please notify Sparke
      Helmore by return email or reverse charges telephone call to
      +61 2 9373 3555 and then delete this message and any copies
      of it. Please also contact us if you have any doubts about the
      authenticity of this email.

      Any legal professional privilege between solicitor and client, or any
      other rights, are retained by Sparke Helmore and are not lost or
      waived because you have received this message in error. This
      email (including any attachments) may also contain computer
      viruses or other defects. Sparke Helmore is not liable for any loss
      or damage that may be caused by these viruses or defects.
    Your message has been successfully submitted and would be delivered to recipients shortly.