smellyrat / drydock

Automatically exported from code.google.com/p/drydock
0 stars 0 forks source link

Ban is buggy #75

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Here's my data from testing the human test:

VALUES ('1', '0', '0', '0', '216', NULL, 'Suspected bot.', 'Suspected
bot.', 'test dat huyman test', '4', '1247173890', 'autoban');

The IP octets don't seem to be correct.  Furthermore, the resulting error
is "abnormal reply" (like when you :getprophet: on 4chan) instead of an
error informing the user they may be a bot.  Is this intended?

Original issue reported on code.google.com by TaQS...@gmail.com on 9 Jul 2009 at 9:20

GoogleCodeExporter commented 9 years ago

Original comment by TaQS...@gmail.com on 9 Jul 2009 at 9:20

GoogleCodeExporter commented 9 years ago
THdie("Abnormal reply");

OH I GUESS SO

Original comment by TaQS...@gmail.com on 9 Jul 2009 at 9:26

GoogleCodeExporter commented 9 years ago
$octets = explode(".", long2ip($ip), 4); -> $octets = explode(".", $ip, 4);

Because $ip = long2ip($ip);

Anyway I guess it's fixed.  As well as any other banning issues we may have 
been having.

But it looks like ban checking is now buggy.  I'll work on this

Original comment by TaQS...@gmail.com on 9 Jul 2009 at 11:43

GoogleCodeExporter commented 9 years ago
SQLite has different syntax than MySQL, and the bans db couldn't be queried and
updated with the same code.

Original comment by TaQS...@gmail.com on 14 Jul 2009 at 8:05

GoogleCodeExporter commented 9 years ago
Banning an entire thread is broken right now because of how sqlite_feth_array() 
(and
therefore $db->myarray()) works.  It doesn't return anything if this:

$replies = $this->myarray("select id from " . THreplies_table . " where 
thread=" . $id);

Warning: sqlite_fetch_array() expects parameter 1 to be resource, string given 
in
dbi\SQLite-dbi.php on line 97

Also post data html (mostly brs and gtgts) get mangled when viewing the bans.  
It's
most likely because of clean() in banip(), but I did a kind of hackish 
workaround
when the ban is actually displayed.

Original comment by TaQS...@gmail.com on 5 Aug 2009 at 5:57

GoogleCodeExporter commented 9 years ago
    function myarray($call)
    {
        if(DDDEBUG==1) { echo ("myarray: " . $call . "<br />"); } 
        $pup = sqlite_query(THdblitefn, $call);
        $dog = sqlite_fetch_array($pup, SQLITE_NUM); // or return null;
        if ($dog === false)
        {
            return (null);
        }
        return ($dog);
    }

Original comment by TaQS...@gmail.com on 7 Aug 2009 at 6:51

GoogleCodeExporter commented 9 years ago
This should be fixed in the svn (apparently) but I will test it later to make 
sure.

Original comment by TaQS...@gmail.com on 7 Aug 2009 at 6:58

GoogleCodeExporter commented 9 years ago
Okay I'm going to retitle this ticket one last time because it still is about 
the bans.

I think that fix for myarray worked (it seems to be fetching all the posts in 
thread
ban, where before it was stopping after the first or just failing completely) 
but now
I'm having issues with banning mangling post data.  I'm again blaming it on 
clean()
and escape_string().  I also took out the nl2br() from banbody() because I know 
for
sure that mangles posts (taking it out also preserved my test post of A CAT IS 
FINE
TOO, which thorn used to break, and is the entire reason nl2br is even being 
used).

I'll commit what I've got and then we can go from there.  I'll give out more 
details
about this later if requested.

Original comment by TaQS...@gmail.com on 7 Aug 2009 at 11:19

GoogleCodeExporter commented 9 years ago
banbody still doesn't accept its default, and there's an issue with this:
This ban duration was set to 1 hours. The ban will expire on 
%08/%25/%09(%pm)%23:%Aug:%th

Both of which are probably easy fixes (I'll fix the last one first)

Original comment by TaQS...@gmail.com on 26 Aug 2009 at 5:29

GoogleCodeExporter commented 9 years ago
Well, I put a workaround in place, where it used to return is banbody wasnt set
(which it should have been because of the function declaration), but now:
        if ($publicbanreason)
        {
            $publicbanreason = '<br /><br /><span class=ban>(' . $publicbanreason . ')</span>';
        }
        else
        {
            $publicbanreason = "<br /><br /><span class=ban>(USER HAS BEEN BANNED FOR THIS
POST)</span>";  //I guess this will work for now
        }

Other than that's it's "Fixed"

Original comment by TaQS...@gmail.com on 26 Aug 2009 at 5:44

GoogleCodeExporter commented 9 years ago
Well, I guess we'll need to fix banbody anyway, because it's mangling again.  It
successfully posts the default message now if the box is left blank, but it also
mangles whatever html is in the box (including old ban messages).  This also 
might be
a problem with editpost.  I'll do some testing.

Original comment by TaQS...@gmail.com on 26 Aug 2009 at 8:10

GoogleCodeExporter commented 9 years ago
Fixed banbody (escape_string, actually) in SQLite.  Fixed I guess.

Original comment by TaQS...@gmail.com on 27 Aug 2009 at 7:18