<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
John,<br>
<br>
Cool. thanks for all of that. I'll put out an update in the morning
(GMT+1 as it's apparently summer, not that anyone has told the
weather forecasters that) in which it will log exactly as it did,
but also spit an error at the user and reject the upload.<br>
<br>
Many thanks for your time trying to reproduce it, that's much
appreciated.<br>
<br>
Cheers,<br>
Jules.<br>
<br>
<div class="moz-cite-prefix">On 08/06/2020 18:31, John Thurston via
ZendTo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!657cdd01d214555d2d4e3c37d3cff900666bb61c0b58288a8ad0c6314246b7e23a7ba78f59abf263b4340d5306980b55!@mx.jul.es">Jules,
we've been beating on this. We are unable to reproduce the
failure, regardless of how we twist or hold our tongues. It is in
the log, so it happened once. We just can't make it happen again.
<br>
<br>
If it never occurs again, that's fine.
<br>
If it does occur and blocks, that's fine too.
<br>
<br>
<br>
re: your earlier questions (GMT -9 here)
<br>
<br>
+ We're using sqlite3
<br>
<br>
+ /opt/zendto/sbin/cleanup.php produced nothing of interest.
<br>
<br>
+ 'dropoff' table schema contains "lifeseconds"
<br>
and "senderIP" is varchar(256)
<br>
<br>
+ I did generate a new cookieSecret, but that was done in the days
prior to performing the test which failed. I don't think it's
related, but if we need an explanation on which to hang our hat,
that might be the only thing we have.
<br>
<br>
--
<br>
Do things because you should, not just because you can.
<br>
<br>
John Thurston 907-465-8591
<br>
<a class="moz-txt-link-abbreviated" href="mailto:John.Thurston@alaska.gov">John.Thurston@alaska.gov</a>
<br>
Department of Administration
<br>
State of Alaska
<br>
<br>
On 6/6/2020 5:03 AM, Jules wrote:
<br>
<blockquote type="cite">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>
On 05/06/2020 19:53, John Thurston via ZendTo wrote:
<br>
<blockquote type="cite">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>
Jules
<br>
<br>
-- <br>
Julian Field MEng CEng CITP MBCS MIEEE MACM
<br>
<br>
'It's very unlikely indeed he will ever recover consciousness,
and
<br>
if he does he won't be the Julian you knew.'
<br>
- A hospital consultant I proved very wrong in 2007 :-)
<br>
<br>
<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
<br>
Twitter: @JulesFM
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
ZendTo mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ZendTo@zend.to">ZendTo@zend.to</a>
<br>
<a class="moz-txt-link-freetext" href="http://jul.es/mailman/listinfo/zendto">http://jul.es/mailman/listinfo/zendto</a>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Jules
--
Julian Field MEng CEng CITP MBCS MIEEE MACM
The current UK shipping forecast:
Shannon: West or northwest 2 to 4 backing southwest 3 or 4. Slight or moderate
in east, moderate throughout in west. Fair then rain. Good, occasionally
moderate.
<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
Twitter: @JulesFM
</pre>
</body>
</html>