* init empty vars to avoid PHP8 warnings
* removed debug output for serendipity_session_destroy()
* init smarty fixed for PHP8
* removed optional parameters for PHP 8
* 2k11 template fixes, maybe updating smarty will solve everything
* init or test undefined variables for PHP 8
* remove only existing files
* make sure string is not empty before comparing the first letter
* check if SMARTY_DIR was already defined
* use mb_language('uni') for unicode
* fixed image filter bug
* Smarty debug fixed in external lib
* fixed archive bug
* fixed entries bug
* updated plugin versions
Co-authored-by: surrim <surrim@happyhydro.org>
The autologin ("Save information") functionality in 2.3.1 is broken since
commit 52a41b37d554da11acc932eeec44c5fb1414a492
CommitDate: Fri Mar 23 18:01:32 2018 +0100
Rework autologin to use a token approach
Although a cookie serendipity[author_autologintoken] with correct
expiration (one month) which random data content is present as value
in the serendipity_options table with name autologin_Username and
correct timestamp as okey and that is found with manually executing
the SQL statement
SELECT name, value, okey FROM serendipity_options WHERE name = 'autologin_Username' AND okey > 1565801743 LIMIT 1
like done in include/functions_config.inc.php
serendipity_checkAutologin(), the login is forgotten after 30 minutes
or so. That was not the case with 2.1.5 where the login was valid for
weeks.
Of
if (stristr($serendipity['dbType'], 'sqlite')) {
$cast = "okey";
} else {
// Adds explicits casting for mysql, postgresql and others.
$cast = "cast(okey as integer)";
}
from which $cast then is used in the SQL statement instead of a plain
okey; when doing that manually with
SELECT name, value, okey FROM serendipity_options WHERE name = 'autologin_Username' AND cast(okey as integer) > 1565801743 LIMIT 1
it produces the MySQL error
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'integer) > 1565801743 LIMIT 1' at line 1
This also with $serendipity['dbType'] = 'mysqli' for the above code.
Indeed, cast(okey as integer) is invalid in MySQL and should be
cast(okey as unsigned) instead which then also works manually, see
https://stackoverflow.com/a/12127022 and
https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html#function_cast
Same in serendipity_issueAutologin().
Changing those two places accordingly resolves the autologin not
persistent problem.
Additionally, inspecting the serendipity_options table revealed loads
of old serendipity[author_authorinformation] cookie information that
was never deleted in serendipity_issueAutologin() with the
OR (okey LIKE 'l_%' AND $cast < " . (time() - 1814400) . ")")
expression producing a MySQL error. This has to be done manually
once as also 2.3.1 will not delete it anymore.
SHA1 is not an ideal password hash, even when salted, because it is cheap to compute. Since version 5.5 PHP offers bcrypt built in, which is a more expensive and secure hash function specifically suited for passwords
The prior code stored encrypted user data in the cookie that was then checked. This new approach is cleaner, as it only stores a token, and it does not use problematic crypto functions deprecated in PHP 7.2
!empty verifies that $username has been set with a significant value of any kind; is_string makes sure the type is really what is being expected in the following code.
Iconfont icons are of no value to screenreader users; in our case,
they get alternative text. By adding 'aria-hidden="true"' to the
<span> holding the iconfont icon, we avoid the screenreader trying
to announce the iconfont icon.
Should've been tested in the alpha, but given the problems with the preview logic (see http://board.s9y.org/viewtopic.php?f=3&t=20791) I'm convinced we need this now. This mainly reworks serendipity_getTemplateFile to follow a simple scheme on where to look for templates – either in the backend or frontend, based on where we are but overridable, then in the engine, then in the defaultTemplate as fallback.
A first approach at fixing s9y for php 7, which makes it possible to
write an entry without any error message. The specific changes are: 1.
__construct for the plugin classes 2. Update Cache Lite to a modern
version to fix its similar constructor problem 3. Remove the
session_regenerate_id call from the session destructor (should get
re-added to session creation where necessary) 4. Remove error handler to
prevent silenced warnings from becoming fatal exceptions
This fixes the plugin tpl fallback for all plugins, already using the parseTemplate() method. All others, which may still follow the themes fallback (like contactform etc), would need to always be part of the user template $serendipity['template'], or be fixed later on.
This also fixes the backend chaining, which now simply follows the force with a possible engine and then uses $serendipity['template_backend'] (2k11), $serendipity['defaultTemplate'] (2k11), 'default'.
As a third, this now uses the correct preview_iframe.tpl file on save and checks for a correct set jquery_backend.js in the user theme $serendipity['template'].
Please double check this approach for cases I did not find yet. Thanks! :)
References #343
PHP 5.4 sets UTF-8 as the default for htmlspecialchars, htmlentities and html_entity_decode. The first two will echo an empty string when given a string with umlauts. This commits introduces serendipity_specialchar-wrapper that are meant to be a temporary solution for the s9y-core until PHP 5.6 fixed the bug, so the native charset option of s9y continues to work.
