NineChime forum

Waccoon wrote:

As a temporary measure I managed to fix it by removing the _ in the pass_reset, mail_check_delete, res_msg and make_thumb...thus it became "passreset", "mailcheckdelete", "resmsg" and "makethumb". The oekaki is working as it is now and I have backed up the files incase I need to change it back.

I sure hope that's temporary, because there's more places in the code where the filtering system will cause problems.  LOTS more places.

Sadly, I have no intention to fool around with the common.php file anymore, because attempts to change it back to w_toalpha() only resulted in a fatal error referencing to common.php on line 67. So my final say is that I have resolved the "No mode" as the way it is when trying to log out by keeping it as w_strict_alpha in the commons.php file and in the functions.php file as well as removing the _ character in the mode functions.

However, be advised that in the near future that if people start complaining that some of the functions are not working after this change, I'll try to get things all sorted out.

Waccoon wrote:

Now, how can I prevent $action functions ("pass_reset", "mail_check_delete" "res_msg") and $mode functions (such as "make_thumb") mode from being affected by this restriction to disallow the usage of the underscore (_)  and other non-alphanumeric usernames?

Go back to the original Wax Poteto "common.php" file and copy the "w_toalpha()" function to your modified "common.php" file.  That will fix the "no mode" problem.  Do not modify the "w_toalpha()" function in the future.

Now, use the "w_strict_alpha()" function I made for you to filter usernames.  If you want to customize a function, make a copy of it and leave the original alone.

While WaxPoteto and Wacintaki are based on the OekakiPoteto 5.x codebase, there were still some bugs that were need to be fixed up. Most of the bugs are easy enough to fix, but some of the them cannot be done without requiring technical support.

I understand there are still some odd problems here and there, but many of the things you're trying to fix are not bugs, but rather design limitations.  It's not a big deal, for example, if the online list fails to specify animated applets or not, or if the index page does not positively highlight administrators.  I tend to avoid fixing these limitations because there are often performance issues, bloat, or secondary effects to consider.  For example, I'm loath to make changes to the database to convert usernames to user IDs, because in-place database conversion is a very dangerous thing to do.  Things can easily get lost, especially since MySQL is infamous for corrupting data when you change too many things at once.  It's better to do a database export and then re-import all the data.  That's a lot of work for only a few features, and I think many people who use the oekaki would simply not bother updating to new versions if this were to happen.

The oekaki is long overdue for a rewrite, but I don't have much time to do that.  Sadly, there doesn't seem to be all that many people out there willing to work on new oekaki boards, either.

That has gotta suck. Based on the fixes that you made as well as the fixes that I made to the files that makes the oekaki function, the oekaki product is long overdue for a complete rewrite. The last time the MySQL mishap and corruption occured on my oekaki was more than two years ago.

As a temporary measure I managed to fix it by removing the _ in the pass_reset, mail_check_delete, res_msg and make_thumb...thus it became "passreset", "mailcheckdelete", "resmsg" and "makethumb". The oekaki is working as it is now and I have backed up the files incase I need to change it back.

Speaking of that, where can I use the "w_strict_alpha()" function to filter usernames without having to interfere with the pass_reset, mail_check_delete, res_msg and make_thumb actions? I've noticed that you can only use it in the commons.php file and the registration part of the functions.php file, but that might not be the case.

I might want to do a backup of my modified files just incase I screw things up again.

Waccoon wrote:

Edit: Wac, I think that I found a solution to the alphanumeric username/JavaScript issue:

This will not work.

You are not allowed to do that.  The "meta http-equiv" is a server-level tag (as it states, it is an "HTTP" equivalent header).  Only "meta name" is reliably visible to the browser.  Furthermore, the <noscript> tag cannot be used in certain contexts, and meta tags are one such invalid context.  Some browsers will allow it, but only if they disobey/ignore W3C recommendations.  Strict browsers will either be confused or will happily ignore the noscript tags in that context (at least, that's what they are supposed to do).

How can I make the $username variable to input only alphanumeric characters?

Technically, you should not convert anything directly into alphanumeric without the knowledge of the registrant.  You are supposed to provide information to the person submitting the registration, so he or she knows that such a name is not permitted.  You can use JavaScript to alert the person right away before they click the "Submit" button, but you cannot rely on JavaScript to actually perform the filtering.  That is a security threat.

I seriously didn't know that attempting to rely on JavaScript to filter out the vulnerability is seen as a security threat. I should be very careful of what I put into the code. Using the noscript tag didn't work. If I get done attempting to fix this vulnerability, I will at least use the noscript tag on the front page to alert the user that they don't have JavaScript enabled.

JavaScript is a client-side technology.  Any filtering solution that uses JavaScript is not a solution.

If you want to really fix this, do the following:

1) Add this to common.php.  Do not change the name of the function:

Code:

function w_strict_alpha ($in) {
    return (preg_replace ("/[^a-zA-Z0-9]/", '', $in));
}

2) Look for this part of functions.php:

Code:

if ($action == 'register') {
    $username = w_gpc('username');
    $email    = w_gpc('email', 'email');
    $age      = decode_birthday($_POST['age_year'], $_POST['age_month'], $_POST['age_day']);
    $pass     = w_gpc('pass');
    $pass2    = w_gpc('pass2');
    $artURL   = w_gpc('artURL', 'url');
    $comment  = w_gpc('comments');

    if (empty ($username)) {
        all_done();
    }

    // Humanity test
    $x_test = w_gpc('x_test', 'i');
    $y_test = w_gpc('y_test', 'i');
    $e_test = w_gpc('e_test', 'i');
    if ($x_test + $y_test != $e_test || $e_test < 2) {
        w_exit('Humanity test failed.');
    }

    // Age verification?
    if ($cfg['op_adult'] == 'yes') {
        if (intval ($_POST['age_year']) < 1900 || intval ($_POST['age_year']) > 3000) {
            report_err('You must submit a valid age declaration (birth year).');
        }

        if (get_age($age) < MIN_AGE_ADULT) {
            report_err('Your age declaration could not be accepted.');
        }
    }

    // Prevent database from vomiting
    if ($bad = badChars(stripslashes ($username))) {
        report_err('Your user name contains illegal characters: '.make_list($bad, ', ', '"'));
    }

Replace the last four lines (the badChars() code block) with this:

Code:

        CUT THIS:

    // Prevent database from vomiting
    if ($bad = badChars(stripslashes ($username))) {
        report_err('Your user name contains illegal characters: '.make_list($bad, ', ', '"'));
    }

        REPLACE WITH THIS:

    if ($username != stripslashes (w_strict_alpha($username))) {
        report_err('Username must contain only letters and numbers');
    }

If you want to do some kind of JavaScript thing on the registration screen to prevent people from even entering non-alphanumeric characters, that's great.  It's better to prevent people from doing things wrong than to beat them over the head with an error message.  However, you cannot rely on JavaScript in any way or form as a replacement for server-side filtering.

That correct. Relying on JavaScript in anyway or form as a replacement for server-side filtering, is definitely not a way to go. Infact, attempting to rely on the w_strict_alpha function resulted in this fatal error message referencing to the common.php file when attempting to add or remove picture thumbnails or when attempting to login or out of my account:

Fatal error: Call to undefined function w_toalpha() in /home/rainbow/public_html/common.php on line 68

I managed to correct it by replacing the w_toa_alpha function with the w_strict_alpha function on lines 67 and 68 in the common.php file. But this is the result when I attempt to add or remove thumbnails:

No mode. Is a server filter being used?

When I looked at the URL address I found that the make_thumb mode has a underscore in it and when the oekaki attempts to perform functions when the underscores (_) are stripped out, the "No mode" error can occur like this.

Now, how can I prevent $action functions ("pass_reset", "mail_check_delete" "res_msg") and $mode functions (such as "make_thumb") mode from being affected by this restriction to disallow the usage of the underscore (_)  and other non-alphanumeric usernames?

Not to be terribly condescending, but I'd like to remind you that due to these types of modifications, your board went offline for weeks and you lost a lot of data.  You may want to ask yourself why you need to keep making these modifications in the first place.

Well...the database itself remained intact during the upgrade, but keep in mind that because of the changes to the way how the piccount and pic_id variables are being handled, the data and the pictures had to be wiped out. I'm trying to recover from all of this mess that I've gotten into over the past two months and at the rate that I'm going, I expect that it'll take several more months to get the oekaki filled up with pictures once again.

So, why have I been making modifications in the first place? While WaxPoteto and Wacintaki are based on the OekakiPoteto 5.x codebase, there were still some bugs that were need to be fixed up. Most of the bugs are easy enough to fix, but some of the them cannot be done without requiring technical support. A site owner like me attempting to further fix or even rewrite parts of the code where the bugs have been found can be time consuming.

It's been a rough two months trying to get my oekaki board back online and I'm almost done. I just need to do a logo for the front page of my oekaki and that's it. I probably might not do further work on my oekaki for a while.


Edit: By the way, on the bright side, attempting to enter non-alphanumeric characters with Javascript disabled returns a error...so it appears to be working now.

First of all, I didn't know where I put the code...so I wound up putting it in the common.php file and I shouldn't do that.

Now, I set up the test file called test-alphanumeric.php and the result was this message:

toalpha(): username invalid

Now, I'm gonna try testing the registration system to see if non-alphanumeric characters return a error. I did a backup of the function.php and register.php files and named the as functions-backup.php and register-backup.php respectively incase these functions either do not work or return a parse error.

Edit: It seems that I'm stuck now.

Somehow, the <b>toalpha(): username invalid</b> error is occurring not just when I attempted to enter a username with illegal characters, such as "#my$name*is/terribly_invalid", but legit usernames that have alphanumeric characters as well. This is what I got in the functions.php file so far:

    // Init -- use addslashes() to simulate input from w_gpc()
    $username = addslashes ('#my$name*is/terribly_invalid');

    if ($username != stripslashes (w_toalpha($username))) {
          w_exit('toalpha(): username invalid');
    }

    // Prevent database from vomiting
    if ($bad = badChars(stripslashes ($username))) {
        w_exit('badChars(): your username contains illegal characters: '.make_list($bad, ', ', '"'));
    }

I'm pretty lucky that I have backup copies of both files, just in case such functions are not working properly.

How can I make the $username variable to input only alphanumeric characters? instead of the "#my$name*is/terribly_invalid" username that always return a invalid username?


Edit: Wac, I think that I found a solution to the alphanumeric username/JavaScript issue:

<noscript>
    <meta http-equiv="refresh" content="0;url=javascript_disabled.php">
</noscript>

I had to create a javascript_disabled.php file to redirect users with JavaScript disabled or have a ad-blocker that interferes with the JavaScript functionality to redirect to that page instead of the registration page.

The noscript tag and redirection will somehow prevent database vomiting if some user attempt to enter non-alphanumeric characters that could cause the database to vomit. If the user has JavaScript enabled, it should automatically redirect to the front page where as if the user has JavaScript enabled, they will have to hit the Register URL link once again.

It might not be a permanent solution for Windows, Mac OS X and Linux users, but it should help solve the non-alphanumeric problem since it relies solely on JavaScript.

I'm gonna do some revision to the javascript_disabled.php file to include instructions on how to enable JavaScript on their browser.

Additionally, I will also place a warning on the front page where as if the user has JavaScript disabled, they must enable it before accessing some of the features on my oekaki site.

Waccoon wrote:

You can only use JavaScript to inform the user if they didn't follow the requirement.  If they have JavaScript turned off, or use some kinds of ad blockers, the code won't work.

You can't rely on JavaScript to filter user data, and you must always verify the POST data on the server with PHP.

I already have a function to test for alphanumeric strings (with spaces and underscores) in common.php:

Code:

function w_toalpha ($in) {
    // Note underscore
    return (preg_replace ("/[^a-zA-Z0-9s_]/", '', $in));
}

USAGE:

if ($test != w_toalpha($test)) {
   // Not alphanumeric!
}

This function allows underscores and spaces.  To change that, remove the underscore and trailing "s" from the regular expression, as follows:

Code:

function w_strictalpha ($in) {
    return (preg_replace ("/[^a-zA-Z0-9]/", '', $in));
}

There's really no need to ban underscores, though.  Only backslahes, quotes, and some rare UTF-8 characters might cause problems.

It's not working at all Wac. I even inserted this code in the common.php file:

if ($in != w_toalpha($in)) {
    // Not alphanumeric!
    report_err('Your user name contains illegal characters!');
}

I even changed the variable from $test to $in and it had no effect at all. I even tried the noscript tag and it had no effect at all.


Also, I did some checking in the functions.php file that references to the register.php file and this is what I found:

if ($action == 'register') {
    $username = w_gpc('username');
    $email    = w_gpc('email', 'email');
    $age      = decode_birthday($_POST['age_year'], $_POST['age_month'], $_POST['age_day']);
    $pass     = w_gpc('pass');
    $pass2    = w_gpc('pass2');
    $artURL   = w_gpc('artURL', 'url');
    $comment  = w_gpc('comments');

    if (empty ($username)) {
        all_done();
    }

    // Humanity test
    $x_test = w_gpc('x_test', 'i');
    $y_test = w_gpc('y_test', 'i');
    $e_test = w_gpc('e_test', 'i');
    if ($x_test + $y_test != $e_test || $e_test < 2) {
        w_exit('Humanity test failed.');
    }

    // Age verification?
    if ($cfg['op_adult'] == 'yes') {
        if (intval ($_POST['age_year']) < 1900 || intval ($_POST['age_year']) > 1999) {
            report_err('You must submit a valid age declaration (birth year).');
        }

        if (get_age($age) < MIN_AGE_ADULT) {
            report_err('Your age declaration could not be accepted.');
        }
    }

    // Prevent database from vomiting
    if ($bad = badChars(stripslashes ($username))) {
        report_err('Your user name contains illegal characters: '.make_list($bad, ', ', '"'));
    }

Somehow, the $bad variable is ignoring the references to characters that are not allowed in a username.

I wonder if there is a way to fix that?