MySQL Bugs: #77710: Bug withh forums

Bug #77710	Bug withh forums
Submitted:	14 Jul 2015 4:14	Modified:	9 May 2018 15:56
Reporter:	Bob Novell	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Websites: forums.mysql.com	Severity:	S3 (Non-critical)
Version:	9898.98	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
I'm not reporting a bug, per say. I am commenting on the support forums.

1) I cannot find any posting rules, such as what can be included and what cannot be included in a posting. For instance, is any HTML code prohibited?

2) The post message and post reply pages are doing something to prevent Firefox from doing spell checking in the input type="text" fields as well as textaras even when you insure that the Check Spelling item in the contextual menu is selected. For those who don't know HTML, an input type="text" field is usually referred to as a single line input area and a textarea is called a multi-line input area.

3) I posted a detailed message about a problem I have and it was held for moderation - that's all I was told. I did not receive any messages about anything being wrong with the posting. I submitted the question twice and neither have been posted.

4) It appears that no one moderates the forums.

5) The software being used (phorum) either lacks some important functions or your configuration (or use of an older version) makes it difficult to go to the next message in a thread. There are links to go to the previous or next MESSAGE but nothing I can find to go to the previous or next post in a thread.

6)Now, you can't do anything about this, consider it just a rant - far too many people who post replies simply don't read or fail to comprehend the question bing asked.

Example - another person posted a message about some of his postings not getting past moderation.

He as asked if he was getting any spam warnings.

He replied in the negative and the next post in the thread says, basically "I don't know why your are getting spam warnings. Come one, if they had read the reply to which they are replying, they would have seen that the person said he was not getting any spam warnings when posting his messages.

Okay, can't do anything about the lack of terrestrial intelligent life - but it drives me crazy when people post without reading or comprehending others postings.

We at STI - Search for Terrestrial Intelligence are still at it but we have nothing to report.

We've had some false results but when examined, those instances turned out to be writings by people long since dead. The most recent instance of that had been written in approximately 10,382 BCE by someone named Hargri. He was writing down some of his thoughts about THE question, you know Life, the Universe, and Everything. He had found that the answer was 42 and came to him that the problem was that no one had actually know what the question was. He found that it was 7 times 6 equal?

That is the latest example of any sort of terrestrial intelligence we have been able to detect.

Ok, end of rant -------------------------

How can I find out why my questions are not being posted?

How can I contact the forum moderator> There is one, right? My questions are being held for moderation so I assume there actually is a moderator but then, any assumptions can be widely incorrect.

Can you shed any light on these issues?

Specifically, what is not allowed in postings? How often does the moderator take a look at the queue of postings awaiting medication?

How can I contact the moderator?

Bob Novell

How to repeat:
I was forced to select a category so I simply chose the first one in the list -MySQL Server X.

I am also required to tell you how to reproduce the bug.

It's simple, try to use the forums to actually get an answer, a relevant and sufficiently detailed, to your questions.

I notice that you don't try to block spam postings in bug reports.

The forum at least use a relatively simple CAPTCHA - Completely Automated Public Turing Test

Hi Bob,

We do have captcha on bugs.mysql.com.

Updated by:  Vlad Safronov
 Reported by: Bob Novell
 Category:    forums.mysql.com
 Severity:    S3 (Non-critical)
 Status:      Open
 Version:     9898.98
 OS:          Any

[14 Jul 12:20] Vlad Safronov

Hi Bob,

We do have captcha on bugs.mysql.com.

---------------------------------
Where?

There is none on the page where you post a new bug - http://bugs.mysql.com/report.php

I don't see anything which even resembles a CAPTCHA.

Have you looked at that page recently?

Bob Novell

Right after I submitted my last comment, it occurred to me, in a split second, that I was logged in and, in another split second, I thought - "I wonder if you get a CAPTCHA if you aren't logged in when you report a bug?"

So, I logged out and went to the but report page, or tried to.

The answer to my question is no, you do no encounter a CAPTCHA when you are not logged in. In fact, if you try to view the bug report page, and you are not logged in, you are taken to the login page.

Unless the CAPTCHA is hidden on the bug report and comment pages, there isn't one.

Looking at the the global aspects of this, an interesting picture emerges.

1 - You have to be logged in to post a new message on a forum or reply to a message.

2 - There is a CAPTCHA on the page used to post a new message and on the page to post a reply.

3 - The bug report page is only available if you are logged in. If not, you are taken to the login page.

4 - There are no CAPTCHAs on bug reporting pages; neither the report page nor the comment page have a CAPTCHA.

Thus, to post a new forum message, or reply to one, you must be logged in, and you are challenged to prove you are a human.

But, and it is a big BUT, when you are logged in and report a bug, or comment on one, it appears that the software author assumes you are human - there is no CAPTCHA.

This means that someone can create an account, login, and then use software to auto- flood you with bogus bug reports. There is no challenge to prove the "poster" is human. If they were to attempt to auto-post messages or replies on the forum, they encounter a CAPTCHA.

This is an interesting dichotomy in the logic used to consider whether or not to present a CAPTCHA to validate the humanity of a forum poster or a bug reporter.

A logged in user is challenged when posting a new message or reply to another message, but when a logged in, is no challenge when reporting a bug or commenting on a bug.

Great consistence in procedures.

The bug reporting procedure assumes you are human because you can't get there unless you are logged in and that seems to be sufficient evidence that you are human.

Where as the forum posing procedure requires that you be logged in and pass challenges you with a CAPTCHA.

I am cognizant that the server software in question may be from a third party - that is, you probably did not write the forum or bug reporting server software or, for that matter, you didn't create the web pages used to interface with server software..

Regardless of whether you wrote the software, this may be a matter of how it is configured.

If it is not a configuration issue, if I were you, I would report this to the authors of the software. - I'm also cognizant that it may be two unrelated third parties involved with the two packages, the forum posting and bug reporting packages.

It was my decision to make, I would require a CAPTCHA on the bug reporting pages. If the software has no option to do so, I would communicate the deficiency to the authors.

Oh, yes, why does textarea (I am specking of a HTML field created with the textarea tag. Fields that people who do not know HTML refer to as multi-line input areas) cause spell checking but those on the post/reply messages on the forum do not?

The textarea on the forum pages is defined as (I'm going to replace less-than signs with [ and greater-than signs with ] in order to get this past any HTML prevention code:

[textarea name="body" id="phorum_textarea" rows="15" cols="50" style="width: 99%"][/textarea]

With that coding, by HTML standards, the textarea will default to spellcheck="true" and, indeed, the Check Spelling entry is selected in the contextual menu. But regardless of the setting of the Check Spelling setting, those textareas do not invoke spell checking.

Also, if you select the Check Spelling item in the contextual menu for an input type="text" field (referred to by people who don't know HTML as a single line input area) spell checking does not occur.

I've been using the Internet since the early 1990s - I think it was 1991 - and, to the best of my recollection, have never encountered a textarea or input type="text" field where spell checking did not occur when the Check Spelling item in the contextual menu was selected.

By the way, I am in favor of input type="text" fields having Check Spelling as the default, as is the case with textarea. I'm going to figure out how to submit an RFC regarding this matter and submit one wherever possible.

It is just as important to spell check the contents of an input type="text" element as it is for a textarea.

Those who decided that only textareas would default to spellcheck="false" but not input type="text" fields, did not fully think through the ramifications.
Let me end the way I began my previous comment.

"Where?"

That is, where is there a CAPTCHA on the bug reporting pages?

Bob Novell

Hi Bob,

Have you tried to comment other people bug reports? I am not a big fan of reCAPTCHA and we are trying to 
reduce spam without much annoying humans with reCAPTCHA.

I received notification of your comment:
-----------------------------------------------
"Hi Bob,

Have you tried to comment other people bug reports? I am not a big fan
of reCAPTCHA and we are trying to
reduce spam without much annoying humans with reCAPTCHA."
-----------------------------------------------

I fail to see how that has any relevance to the issue at hand.

I went to the comment page to post a comment on someone else's bug report and, yes, there is a CAPTCHA.

So, one of the three possible posting situations challenges the poster with a CAPTCHA:

The three situations are:

1) The posting of a new bug report

2) The posting of a comment by the person who reported the bug.

3) The posting of a comment on a bug report created by another person.

You only address number three.

But number three is not the issues here. The issues are number one and two.

Sure, it's good that one of the posting situations is protected, but in security one out of three is a failing grade.

Remember, there is the difference in the approach to security in forum software and in the bug tracking software - or at least in the configuration settings.

Both features require that you be logged in to post anything but the forum software challenges you every time you post and the bug tracking software only challenges you when post a comment to a bug reported by another person.

I am curious as to whether the CAPTCHA present on number three is caused by a confirmation option. If so, perhaps the same setting can be used to create a CAPTCHA in situations one and two....

Have you looked at the approach used by Akismet? I'm including another URL here and wondering if you'll see it: http://akismet.com/

Yes, I know that this adds more processing and time to the posting of an item, but I've found it to cause a relatively insignificant impact.

I have a blog which I first implemented with no spam control and allowed anyone to register. Within maybe an hour, a multitude of fake logins were being created and spam comments being posted.

I turned off the "allow anyone to register" option and that did away with the fake registrations.

I then implemented the Akismet plugin and the number of spam comments getting past the filters dropped to zero. I still get spam comments but they are filtered out and moved to the spam folder. I occasionally skim through them and then delete them but at least they are not being posted on the blog.

I just went and check on it, and there were 59 copies of effectively the same spam that had been filtered. All of the comments which were allowed are real comments.

The spam which were caught contained perhaps 100 or 150 links. The combination of setting a small allowed number of links and the use of Akismet works perfectly.

I think I'll go remove the number of links setting and see what happens.

The experience of all of the people who I've found have commented about the effectiveness of Akismet says that it works and in some cases it is the only spam filter implemented and any number of links are allow.

But, I digress...

As I said, I fail to see the relevance of the fact that one out of three posting situations is covered with a CAPTCHA.

And there is still matter of not being able to invoke spell checking on the forum textareas.

Bob Novell

Sorry, I forgot something in my last comment -

I've still not received any replies to my messages about forum moderation.

Is there any? If so, when is it done?

Exactly what causes a posting to be held for moderation?

I read bug report about someone trying to post a message and having it rejected because it used a banned word. He asked that a modification be made to show the banned word so that he could change it.

You added a comment saying that you had verified it and had changed specialist to guru and that resolved the problem.

But the bug is still unresolved.

The bug is #75239.

Why on earth is the word "specialist" banned?

I agree with the reporter that the banned word or words should be displayed so the poster can actually know which what is banned.

Just saying that a word has been banned is of absolutely no help the the poster.

If you are concerned that the words might be profanities, your displaying them in the error message is not going to offend the original poster of those words.

Both the display of the error message and the rejection of the word "specialist" should be address quickly.

It is a really stupid problem. If it were me, or someone who I supervised, directly or indirectly, this bug would be hunted down and shot and the code displaying the error message would be changed to display the banned word and these changes would be assigned a high priority just because of the stupidity of the problem.

After all, programmers write programs and programmers can change them - provided they don't introduce new problems with the changes made to resolve the original problem.

Test, test, test, test, and test some more. You can never test too much - period

Bob Novell

Hi Bob,

Just as I said above we are are trying to reduce spam, not to annoy humans with reCAPTCHA.

Akismet is a nice solution for a private blog or news media. Submitting users comments to Akismet site? :) No, thanks. 

Let's wait until our forums support team will fix your issue.