<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Can anyone reproduce this?<br>
    <br>
    The only way you can reach the bit of code that generates the log
    message is if there is a form input called "req" which is used to
    hold the 9-digit number (or string of 3 words) that make up the
    request code. And "req" must have a non-empty value.<br>
    <br>
    Unless you're responding to a request, this form input is always
    empty.<br>
    <br>
    John — One final question: During the upgrade, did it tell you to
    generate a better cookieSecret? And did you do so? Changing the
    cookieSecret while it is in use can also break things for users who
    happen to be logged in and interacting with the website at the time
    you change cookieSecret.<br>
    <br>
    <div class="moz-cite-prefix">On 05/06/2020 19:53, John Thurston via
      ZendTo wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:WM!52c4b25d726d92338a78a7699c4ed89882db7b238eb0b8ca50736372375e32786406e2f71ed1286c67f8e624cab4157d!@mx.jul.es">I'm
      looking at moving from V5 to V6. During testing, we turned up
      interesting behavior.
      <br>
      <br>
      While creating a drop-off, the authenticated customer was prompted
      for a passphrase. This was entered and accepted. Checksum was also
      requested.
      <br>
      <br>
      When the upload was complete, the 'Outbox' showed the files with
      an "X" in the encrypted column. When later performing the pickup,
      no passphrase was requested.
      <br>
      <br>
      When I later looked in the logs, I found:
      <br>
      <blockquote type="cite">Error: Should be encrypting files but
        failed to read the passphrase, so not encrypting. If this
        drop-off came from a request, the encoded passphrase in the
        request got corrupted!
        <br>
      </blockquote>
      <br>
      which I traced to line 2531 of NSSDropoff.php
      <br>
      which is preceded with the comment block
      <br>
      <br>
      <blockquote type="cite">// If we got the encryption passphrase
        from a request, but failed to
        <br>
        // be able to read it, the user won't have been prompted to
        enter one.
        <br>
        // So we have no way of finding it! So if that failed, don't
        encrypt
        <br>
        // at all.
        <br>
      </blockquote>
      <br>
      But this drop/pickup didn't originate with a 'request'. It was
      done by an interactive, authenticated user. The user requested
      encryption, supplied the phrase, and the application seems to have
      quietly failed to encrypt an otherwise acceptable (not too large)
      file.
      <br>
      <br>
      I'm unable to reproduce this failure.
      <br>
      <br>
      If the customer asks to encrypt an over-sized file, it is plainly
      refused. If encryption has been requested and can't be done for
      some other reason, shouldn't that be a blocking-situation?
      <br>
      <br>
      <br>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">Jules

-- 
Julian Field MEng CEng CITP MBCS MIEEE MACM

'It's very unlikely indeed he will ever recover consciousness, and
 if he does he won't be the Julian you knew.'
  - A hospital consultant I proved very wrong in 2007 :-)

<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
Twitter: @JulesFM
</pre>
  </body>
</html>