<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I would certainly hope a password manager isn't auto-filling a
hidden input called "req"!!<br>
If there's something that's doing that, we're all doomed. Password
managers are usually written to avoid "over-filling" forms, so as
not to give away passwords to sneaky forms that have a field for it
but disguise the fact.<br>
<br>
But I've been trying to break it again this morning, and I still
can't.<br>
<br>
Cheers,<br>
Jules.<br>
<br>
<div class="moz-cite-prefix">On 06/06/2020 16:35, Mailing Lists via
ZendTo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:WM!676e1006b457a7398f8075bba2c7df2269785330e94f9e3133b3713b5169c06fadf2346076cab7de2bb719b8c58d760f!@mx.jul.es">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
maybe a password manager autofills the field without notice?<br>
<br>
<div dir="ltr">via Smartphone</div>
<div dir="ltr"><br>
<blockquote type="cite">Am 06.06.2020 um 15:03 schrieb Jules via
ZendTo <a class="moz-txt-link-rfc2396E" href="mailto:zendto@zend.to"><zendto@zend.to></a>:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
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" moz-do-not-send="true">www.Zend.To</a>
Twitter: @JulesFM
</pre>
<span>_______________________________________________</span><br>
<span>ZendTo mailing list</span><br>
<span><a class="moz-txt-link-abbreviated" href="mailto:ZendTo@zend.to">ZendTo@zend.to</a></span><br>
<span><a class="moz-txt-link-freetext" href="http://jul.es/mailman/listinfo/zendto">http://jul.es/mailman/listinfo/zendto</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ZendTo mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ZendTo@zend.to">ZendTo@zend.to</a>
<a class="moz-txt-link-freetext" href="http://jul.es/mailman/listinfo/zendto">http://jul.es/mailman/listinfo/zendto</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">Jules
--
Julian Field MEng CEng CITP MBCS MIEEE MACM
'Gaze not into the abyss, lest you become recognised as an abyss
domain expert, and they expect you to keep gazing into the damn thing.'
- @nickm_tor
<a class="moz-txt-link-abbreviated" href="http://www.Zend.To">www.Zend.To</a>
Twitter: @JulesFM
</pre>
</body>
</html>