Bug #20379
closedGenerate Random Key still does not work
0%
Description
Generate random encryption key does not work. This was worked on and delt with in #0010212. This patch was for 4.3.0-alpha1.
I have installed 4.3.0-alpha2 and I am having the same issue.
Is this fixed or not? What can I do to make it work? the files attached to #0010212 don't do a general user like me much good.
(issue imported from #M11013)
Files
Updated by Marcus Krause over 15 years ago
Do you have any further data? e.g. Browser
Updated by Robert Brien over 15 years ago
Thanks for the idea. It didn't work in Internet Explorer or Google chrome but did work in Firefox.
Updated by Christian Leicht about 15 years ago
Testet with a new installation from svn on 1.Sept. 09 with Firefox 3.5.2 on Vista, the generate Button doesent work.
Christian
Updated by Marcus Krause about 15 years ago
I've tested FF 3.0.12 on RHEL 5.3, FF 3.5.2 on Win XP and Opera 9.64 on WinXP. It works for me in all these cases. (was using trunk as of rev 5878)
However, in IE8, i can confirm that generating anm encryption key works only once at the first request.
Please provide further data or better, debug it, so that we are able to reproduce!
Thanks.
Updated by Marcus Krause about 15 years ago
We now isolated two different issues:
1. Caching problem with IE8 - regeneration in the install tool succeeds only one time. (patch locally existing)
2. Generation of an encryption key via eID does not work at all - still digging into it
Updated by Steffen Kamper about 15 years ago
I uploaded the patch for IE8 (cacheing issue)
Still: on local installation (trunk) the eID script is never called, so response is empty. It works online. Has to be examined.
Updated by Marcus Krause about 15 years ago
Both problems exist only for trunk.
1. Caching: missing cache control headers from #19998
2. Not working eID: sysext install is not in $TYPO3_CONF_VARS['EXT']['extList_FE']
Updated by Rupert Germann about 15 years ago
I can confirm that introduction of extList_FE causes this problem.
That brings up the question: is it really a good idea to require "install" to be loaded in TYPO3_MODE = FE? just to handle this single ajax call which normally happens once per installation.
Updated by Steffen Kamper about 15 years ago
i thought about all possibilities.
There are 2 possibilities which i see,
Make a low level ajax call to a file that only does this:
(pseudocode)
include(typo3conf/localconf.php);
include(t3lib/t3lib_div.php);
if ($_GET['cmd'] == 'encryptionKey') {
$bytes = t3lib_div::generateRandomBytes(96);
echo substr(bin2hex($bytes), -96);
exit;
}
?>
or use ajax.php like all scripts in BE. Even if it takes some more time, it won't be called very often
Updated by Rupert Germann about 15 years ago
ajax.php will not work because it is not shure that we already have a DB connection at this point
Updated by Oliver Hader about 15 years ago
I think we should check #19998 again and commit it also to Trunk...
Updated by Marcus Krause about 15 years ago
Attached patch 11013_v2.diff brings #0010410 to trunk.
Updated by Marcus Krause about 15 years ago
The eID usage for the AJAX-Call has been accepted and implemented way back.
Therefore, I personally see no need to discuss it once again. Trunk and 4-2 already use eID for it. A lowlevel solution like suggested IMHO is a "frickel" solution. For readability and keeping maintaining the codebase easy I suggest to leave it as it is.
Clearly, the 5766 changeset broke things here. So reverting it for sysext:install is a proper solution. You could even fix it now by reverting it, have a working version now and discuss a different solution later.
Feel free to provide whatever solution you like. I'm hereby detaching myself from this issue.
Updated by Steffen Kamper about 15 years ago
v2 is in core list and is the proper solution.
Updated by Rupert Germann about 15 years ago
committed attached v3 to trunk rev 5995
only difference to v2 is that "doNotLoadInFE" is no longer set in the extension "install".
successfully tested in IE7/8 and in FF3