<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
John,<br>
<br>
If you are using MyySQL as the back-end, the output from "SHOW
CREATE TABLE dropoff" should be this:<br>
<br>
`rowID` int(11) NOT NULL AUTO_INCREMENT,<br>
`claimID` varchar(16) NOT NULL,<br>
`claimPasscode` varchar(16) DEFAULT NULL,<br>
`authorizedUser` varchar(255) NOT NULL,<br>
`senderName` varchar(32) NOT NULL,<br>
`senderOrganization` varchar(32) NOT NULL,<br>
`senderEmail` varchar(255) NOT NULL,<br>
`confirmDelivery` tinyint(1) NOT NULL DEFAULT '0',<br>
`senderIP` varchar(256) NOT NULL,<br>
`created` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE
CURRENT_TIMESTAMP,<br>
`note` text NOT NULL,<br>
`lifeseconds` int(11) NOT NULL DEFAULT '0',<br>
PRIMARY KEY (`rowID`),<br>
KEY `claimID` (`claimID`)<br>
<br>
The length of the "senderIP" field should be at least 256. If that
field is shorter, that could (don't ask!) explain it.<br>
<br>
Cheers,<br>
Jules.<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
'Once is happenstance, twice is coincidence, three times is enemy
action.' - Ian Fleming
<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
Twitter: @JulesFM
</pre>
</body>
</html>