Without admin permissions (member of user class 254) it was not possible to modify threads in
the forum. This fix get the forum-moderator permissions by the threadId to modify this thread.
I am working further on the moderator permissions and discovered that my previous commit
692509f is a bad solution. Because the moderator submits the threadId and postID for the post
who he wants to delete. This threadId was used to check the moderator permissions of the postId.
So if a moderator has only permissions for one forum, he could change the transmitted threadId
in an other forum to get there also moderator permisssions...
Sorry that I did not noticed this glitch before I made the previous commit. :-/
Without admin permissions (member of user class 254) it was not possible
to delete a post in the forum. This fix add the threadId to the ajax query
and fetchs the forum-moderator for the thread which will then checked
against the user permissions/classes.
I added also an additional error message, if something goes wrong.
Parent links in sitelinks_alt::sitelinks_alt_shortcode() now have their
button image URI parsed by e_parse::replaceConstants(), bringing it into
consistency with the children, which are already parsed the same way.
There is no corresponding test for this in e107-test because hard-coded
dependencies in sitelinks_alt::sitelinks_alt_shortcode() are difficult
to monkey-patch without crippling the performance of e107-test.
This "inline token" is generated 30 times in my test, but it's the same
session_id() being hashed. This is wasteful and can be mitigated in two
ways:
* Reducing the time cost like so: return password_hash(session_id(),
PASSWORD_DEFAULT, ['cost' => 04]);
* Storing the hash as an instance variable the first time it's
generated
This commit applies both mitigations.
