hgm wrote: ↑Tue Sep 14, 2021 1:59 pm
I have not had a single '403 Forbidden' error on talkchess.com today, which is very unusual, as these past months I could virtually never connect. But I discovered something interesting. I took a look in the board's 'admin log', which lists the IP addresses from which the admin connects. This would obviously only be IP addresses that were not blocked. The interesting thing is that they are all different.
Since we are using CloudFlare as a proxy, I assume that all these IP addresses are form the CloudFlare server.
OK, this problem is solved now. The final step to make it work was disable the sortables captcha in the extensions manager, and then enable it again. There might have been another problem that contributed (which I had solved before), which was that I had forgotten to transfer ownership of the captcha files from root to www-data after installing the files.
The only remaining problem I am aware of now is that the polls still do not work. So I would like to debug that.
What I could figure out so far is that topics that contain a poll display this poll as a HTML 'form' containing some radio button 'input' elements, and a 'submit' button:
The form 'action' (presumably triggered by pressing the submit button) uses the same URL as for the page that displayed the poll, but can probably be recognized from the fact that it uses a POST method to access the server, rather than the normal GET. This should trigger the PHP script it invokes (viewtopic.php) into processing the vote. This apparently doesn't always work.
Now the problem is that I don't speak PHP. So I could use the help of someone who does, in order to suggest where I could slip in some statements that would provide debug output in this viewtopic.php script, to diagnose what is going on. This script can be seen at https://github.com/phpbb/phpbb/blob/mas ... wtopic.php .
But where would that be printed? In some file on the server? Or would it be sent to the client? And do you have any idea which section of viewtopic.php is responsible for processing the vote?
hgm wrote: ↑Wed Sep 15, 2021 1:29 pm
But where would that be printed? In some file on the server? Or would it be sent to the client? And do you have any idea which section of viewtopic.php is responsible for processing the vote?
As long as the print_r comes after the http header it will printed by PHP into the HTML document, somewhere on the screen. Maybe put an
echo "my debug:";
before the print_r to find it.
If you are in mixed HTML and PHP mode you can use:
<?php
echo "my debug:";
print_r($var);
?>
I guess it is an database flag issue, cos some users can vote, some not, hence the scripts themselves seem to work. I will take a look into v3.3.4 and maybe figure some SQL commands for you to check if a user has the right to poll - just guessing.
hgm wrote: ↑Wed Sep 15, 2021 1:29 pm
But where would that be printed? In some file on the server? Or would it be sent to the client? And do you have any idea which section of viewtopic.php is responsible for processing the vote?
As long as the print_r comes after the http header it will printed by PHP into the HTML document, somewhere on the screen. Maybe put an
echo "my debug:";
before the print_r to find it.
If you are in mixed HTML and PHP mode you can use:
<?php
echo "my debug:";
print_r($var);
?>
I guess it is an database flag issue, cos some users can vote, some not, hence the scripts themselves seem to work. I will take a look into v3.3.4 and maybe figure some SQL commands for you to check if a user has the right to poll - just guessing.
--
Srdja
The users seem to have the right to vote according to viewtopic.php $s_can_vote defined in line 907, hence I should debug how the vote is piped through the scripts into the database, but according to Ed's recent posting Quentin seems not ok with the clone, so I will stop working on it for now until there is some kind of agreement between the founders resp. green light from Quentin.
Well, Ed's fake news is doing a lot of damage. In fact Quentin has no objection at all against the TalkChess poll function getting fixed. And it makes absolutely no sense that he should.
BTW, looking at the code I noticed there is a variable $update, which is used in conjuction with $s_can_vote to decide whether the code for updating the vote counts should be executed. It seems to be initialized from a CGI argument, defaulting to false. When I append "&update=true" to the URL for showing the poll, indeed something happens: I don't get to see the poll. Instead I get an error page that complains no options were ticked. Which is no doubt a consequence of that I wasn't really submitting a form (so no values for voted_id).
It this a standard CGI parameter that always gets set to true by the browser whenever you submit a form? I notice that the 'action' that is specified for the form (shown in an earlier posting) is an URL that doesn't contain the update=true parameter. Can this be the cause of the problem? Note that the shown HTML is just the page source of the page that was shown to me; other people might see a page that does have the update=true in the action, and these would then be able to vote. If this is the case, we would have to look at the script that prepares this page. (Which also is viewtopic.php, but a different section of code.)
