Task force TalkChess access

[smatovic]

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.

This story reminds me too much of the CTF case, I am just the tech guy, here to fix the tech.

...so I will stop working on it for now until there is some kind of agreement between the founders resp. green light from Quentin.

***edit***
We have here three parties, the founders, the elected moderators, the hosting-sponsor/site-owner, not my job to do the politics.

--
Srdja

[hgm]

Well, perhaps someone else is still willing to help debugging this?

I have figured out now (in FireFox, opening the 'developer panel' with F12, and selecting 'network', so that it shows me what the browser sends to the server), that pressing the 'Submit vote' button in the poll at http://212.114.109.12/tc/viewtopic.php?f=2&t=78124 issues the POST request to that same URL. Unfortunately it doesn't show me the actually posted data. Which, according to the HTML tutorials I could find, should contain of all name=value pairs of the <input> elements in the <form> that is being submitted.

As we can see in the page source of the poll page shown in a posting above, the submit button (labeled 'Submit vote') is actually inside that form, together with the radio buttons indicating the vote. The 'name' attribute of the submit button is 'update', and the 'value' attribute is 'Submit vote'. So I would expect an "update=Submit vote" argument to be present in the POSTed data.

But I rigged the viewtopic.php script to crash with an error whenever update != false. And it doesn't crash. So it seems that my browser does not send the name=value pair of the submit button in the POSTed form data. Which would explain why the vote could not be submitted before I rigged the server-side code to crash on an attempt to do so. But it does seem an HTML error of the browser?

[hgm]

Ah, some progress! I tried to print the body of the POST request (var_export($_POST)) as debug output on the page, but since the POST request itself doesn't result in anything being shown when the PHP voting code is not exectuted, this did not work. Then I found an alternative method to detect if the PHP script is invoked by a POST request:

$update = (filter_input(INPUT_SERVER, 'REQUEST_METHOD') === 'POST');

So then $update gets set to true even when there is no "update=true" passed as parameter to the POST request generated by the "Submit vote" button. And guess what? The voting worked! I was able to submit an 'OK' vote in the test poll, so that there are now 3 votes. And I am no longer offered the possibility to vote when I open the topic: the "Submit vote" buton is gone, and the results of the poll are shown immediately (without the need for a viewpoll argument to the URL, which would be needed to see the results for those that haven't voted yet).

So it seems the only problem is that the POST request for submitting the voting vorm fails to relay the "update=Submit vote" parameter, even though an <input> element is present inside the form with name=update and value=true. (Namely the "Submit vote" button itself.) The phpBB software seems to rely on it that it does. And perhaps it does with some browsers or browser versions. Which would explain why some users were able to vote, and others not.

People are invited to vote in the poll ( http://212.114.109.12/tc/viewtopic.php?f=2&t=78124 ), to test if it now works for everyone.

(Of course a more fundamental fix still has to be found, as I am not sure that phpBB would not use POST requests to viewtopic.php that do not have a Submit button with name=update, and should trigger other actions than vote updating. These actions would now be broken, because they would all invoke the voting code.)

[ydebilloez]

to test if it now works for everyone.

I really appreciate your effort for the compute chess community! Great and many thanks.

I did select an option that had zero votes and this increased to one.... so worked for me.
Question, why would you show the results to anyone that didn't vote yet?

[hgm]

This is apparently a standard phpBB option: initially you are not shown any results, but there is a link "View results" under the Submit-vote button, which would display the page again with an extra view=viewpoll argument to the URL. Which forces showing of the results. Perhaps this can be disabled during the creation of the poll. (Or it could be this option only exists for admins...)

[hgm]

I still don't get it. In a freshly created forum (such as the one at http://212.114.109.12/new ) voting in the polls does work, with the same browser. Apparently the 'update' parameter does get a value in the POST request there. But the HTML for the form looks the same; there isn't any extra "&update=..." in the URL, so it must get its value in the POST data. It is a real pity that the FireFox developer panel only shows me the header of the POST request. I would really want to know what is in the posted data.

But it remains strange: it seems to me that the generation of the POST data for the vote-submission form is purely something that the browser does, under direction of the HTML that defined the form. So how can 'update' get a value in one case, but remain at the default in another, if the HTML defining the <form> superficially is identical?

[towforce]

In this post - link - I can see the board, but not the pieces on the board.

From the console in Chrome Developer Tools, I am seeing several instances of the following error:

Failed to load resource: the server responded with a status of 403 (Forbidden)

[hgm]

The piece images come from my server (hgm.nubati.net). So if they do not load, the problem is likely there. At the moment I do see pieces, so the server must be OK again. (Even when I clear the cache. Normally the piece images would already have been cached by your browser, so that they would display on TalkChess pages even when my server is down.)

[smatovic]

Regarding logouts on TC (the original):

On prev forum versions the session-id was submitted via GET in the URL as sid, now the session-id is stored as cookie. You can view the values in FireFox with F12 and then click on Storage. Both methods should be resistant to an IP address change on client side AFAIK. When I get logged out the session-id in the cookie changes.

I mentioned already two modules to restore the original IP address (hidden by Cloudflare), one for phpBB and one for the webserver:

https://www.phpbb.com/customise/db/exte ... masked_ip/

https://support.cloudflare.com/hc/en-us ... 97z77b3XZV

I don't know what the logouts causes, IIRC these started to appear with the activation of Cloudflare. Maybe somebody with some Cloudflare experience can chime in and give some expertise about sessions, cookies, PHP and Cloudflare.

An update to the current version of phpBB is always recommended, to sieve out potential bugs.

--
Srdja

[mvanthoor]

Regarding logouts on TC (the original):

On prev forum versions the session-id was submitted via GET in the URL as sid, now the session-id is stored as cookie. You can view the values in FireFox with F12 and then click on Storage. Both methods should be resistant to an IP address change on client side AFAIK. When I get logged out the session-id in the cookie changes.

I mentioned already two modules to restore the original IP address (hidden by Cloudflare), one for phpBB and one for the webserver:

https://www.phpbb.com/customise/db/exte ... masked_ip/

https://support.cloudflare.com/hc/en-us ... 97z77b3XZV

I don't know what the logouts causes, IIRC these started to appear with the activation of Cloudflare. Maybe somebody with some Cloudflare experience can chime in and give some expertise about sessions, cookies, PHP and Cloudflare.

An update to the current version of phpBB is always recommended, to sieve out potential bugs.

--
Srdja

If you use Dark Reader in Firefox or Chrome / Chromium, it will logout Talkchess when the rendering is set to Dynamic. I reported it on Dark Reader's GitHub, but they set it to "wontfix" because "rendering options can't cause logouts." (Meanwhile, lots of sites are reported as not working, not logging in, or not staying logged in...)

If you use Dark Reader, enable the new Preview Layout, and then create a profile for Talkchess with "Filter" or "Filter+" (Filter+ doesn't work well in Firefox) for Talkchess specifically. Then it'll stay logged in.