The autologin ("Save information") functionality in 2.3.1 is broken since
commit 52a41b37d5
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.
This reverts commit d9b3333556.
With this - now reverted - commit, the prev/next
arrows in pagination were swapped because they
were the wrong way around. Unfortunately, later on,
in ebb852d400, the
root cause was fixes by "unswapping" the prev/next
links in core, so now the pagination arrows were
... eh ... wrongly swapped. So this commit has to
be reverted.
Should fix#625 for good this time.
Signed-off-by: Thomas Hochstein <thh@inter.net>
"serendipity_lang_pt_PT.inc.php" is mixed
case and won't be found if languages are
normalized to lowercase.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The plugin name was derived from its
install path - but bundled sidebar and
event plugins may share a path. So use
the name instead (and strip the instance
hash from it).
Signed-off-by: Thomas Hochstein <thh@inter.net>
If you have the additional_plugins repo handy,
you can just change the base path to check all
that plugins, too.
We shouldn't forget to check the UTF-8
directories.
And we just have to catch all, even fatal,
errors, due to missing function dependencies.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Unconditionally setting $serendipity['csuccess']
to 'true' will override a "moderate" flag set by
another (spamblock) plugin.
Signed-off-by: Thomas Hochstein <thh@inter.net>
We shouldn't swap prev/next links for archive
pages. With stable archives, the title page is
the last page of the archive, not the first, so
all other pages are "previos", and we should
display it like that.
That may seem counterintuitive at first, but
otherwise archive page directions and pagination
directions don't match (see bulletproof), and we
shouldn't count archive pages differently from
the URL. With the current code, page 100 of 100
archive pages would be shown in footer_info as
page 1, page 99 as page 2, and that doesn't make
sense either.
Signed-off-by: Thomas Hochstein <thh@inter.net>
Timeline and Bulletproof have pagination.
Both need to swap the prev/next links for
stable archives, as the sorting order has
been reversed.
Signed-off-by: Thomas Hochstein <thh@inter.net>
The current page will always be the current page,
regardless of archive sorting order. Page 76 of
86 pages will remain page 76, even if the archive
sorting is changed; it won't become page 10.
Fixes#625 in core.
Themes will have to cope with the sorting order
in their pagination code if they want to display
a descending order for stable archive sorting.
Signed-off-by: Thomas Hochstein <thh@inter.net>
