1,576

(28 replies, posted in PunBB 1.2 troubleshooting)

quaker wrote:

Mattf, now.. here goes. is there a site that list IP to totally block user? say u go to my site and if your ip is listed it will block the site 100%?

List the IP on what criterion? If you're going down a full access block route, you should be doing this at network level, not software level, i.e: firewall.

Edit: If you are going to do it at software level, I would presume including that script from header.php itself would do the trick. Header.php is a common requirement across all forum pages.

1,577

(28 replies, posted in PunBB 1.2 troubleshooting)

If their account isn't activated, they cannot login, hence they're a guest? Wouldn't just disabling guest viewing achieve the same?

You may be able to adapt this to cater to your requirements. It'll at least give you a starting point for rolling your own if not. smile

http://techpatterns.com/downloads/scrip … ection.txt

1,579

(28 replies, posted in PunBB 1.2 troubleshooting)

quaker wrote:

hummm that might be a good mod. a blocking script via ip address and a redirect to some stupid site.

if ip is listed then redirects.

You could easily add a redirect inplace of the rejection message, but that wouldn't honestly be a good idea. You will get false positives on occasion. Legitimate users shouldn't be required to have to jump through hoops just to register. That idea would penalise legit users big style.

1,580

(28 replies, posted in PunBB 1.2 troubleshooting)

fredrikn wrote:
MattF wrote:
fredrikn wrote:

I blacklist email-domains in this way, but the spammers still register. What am I doing wrong?

I have "Allow banned e-mail addresses" set to "no". I create a ban containing just the email-domain (without the "@") without any username... sad

You are entering the parent domain in the banned e-mail list? Do you have another PunBB running, using the same db?

I have a single PunBB running. I enter "domain.tld" to block "user@domain.tld", which I assume is the correct syntax.

Yup. That's correct. smile

1,581

(28 replies, posted in PunBB 1.2 troubleshooting)

quaker wrote:

mattf, what does this do? are you modifying the register.php or some sorta blockage script for those listed.

It does exactly the same as that original code you posted, except for the fact that you can specify multiple RBL's to check against with this one. It's just a modified version of that initial code you posted. smile The script is placed at the same place in register.php as you mentioned above. That's why it needs the header/footer parts adding with the reject message. smile

1,582

(28 replies, posted in PunBB 1.2 troubleshooting)

Just been playing around with this in PunBB itself. It needs the header/footer adding too, otherwise it will just blank screen. I assume this applies to the original code posted initially to boot.

//---------------Start of RBL lookup---------------//

$rblserver = array();
$rblserver[] = 'sbl-xbl.spamhaus.org';
$rblserver[] = 'combined.rbl.msrbl.net';

$fip = get_remote_address();
$rip = implode('.', array_reverse(explode('.', $fip)));


foreach ($rblserver as $xrbl)
{
        $rblcheck = $rip.'.'.$xrbl;

        if ($rblcheck != gethostbyname($rblcheck))
        {
                $page_title = pun_htmlspecialchars($pun_config['o_board_title']).' / '.$lang_register['Register'];
                require PUN_ROOT.'header.php';
                message("Your I.P address: ($fip) is blocked due to it being listed in the $xrbl database.");                         
                require PUN_ROOT.'footer.php';
        }
}

//----------------End of RBL lookup----------------//
CodeXP wrote:

Think I'll stay away from the pbl blocklist for checks such as this (and just use the PBL and XBL),

The PBL section of Spamhaus is designed for use upon MX servers, not web servers. It bears no relation to anything web based. The sbl-xbl list is the one best served for web use. The zen list, (or the pbl list alone), should only be used for MX servers and nothing more.

1,584

(28 replies, posted in PunBB 1.2 troubleshooting)

Here's a multi-rbl variation of that code Quaker posted.

//---------------Start of RBL lookup---------------//

$rblserver = array();
$rblserver[] = 'sbl-xbl.spamhaus.org';
$rblserver[] = 'combined.rbl.msrbl.net';

$fip = get_remote_address();
$rip = implode('.', array_reverse(explode('.', $fip)));


foreach ($rblserver as $xrbl)
{
        $rblcheck = $rip.'.'.$xrbl;

        if ($rblcheck != gethostbyname($rblcheck))
        {
                message("$fip blocked. Your I.P address is listed in the $xrbl database.");
        }
}

//----------------End of RBL lookup----------------//

Only lightly tested. smile You can add more RBL's if required, (though not necessarily a good idea), by adding more:

$rblserver[] = '[another-rbl-server]';

lines below those two already there. Those two should suit for general use, however.

erik98 wrote:

where can i access it?

Search on punres.org. smile

1,586

(28 replies, posted in PunBB 1.2 troubleshooting)

fredrikn wrote:

I blacklist email-domains in this way, but the spammers still register. What am I doing wrong?

I have "Allow banned e-mail addresses" set to "no". I create a ban containing just the email-domain (without the "@") without any username... sad

You are entering the parent domain in the banned e-mail list? Do you have another PunBB running, using the same db?

1,587

(38 replies, posted in PunBB 1.2 bug reports)

hsn wrote:

best way for programing db apps in pgsql is to use stored procedures. They runs faster than
sending multiple queries to db, you can easily handle cases like this in stored procedures.

CREATE OR REPLACE FUNCTION bb_login(user_id text, ident text, logged timestamp) returns void as '
DECLARE
rows integer;
BEGIN

UPDATE online SET logged=current_timestamp WHERE user=user_id;

GET DIAGNOSTICS rows = ROW_COUNT;

IF rows = 0 THEN
  INSERT INTO online (user_id, ident, logged) VALUES(user_id,ident,logged);
END IF;
END;
'
language 'plpgsql';

That one is way over my head. big_smile Where/how would that code be placed to utilise it?

1,588

(38 replies, posted in PunBB 1.2 bug reports)

Smartys wrote:

OK, ignore me, it appears that the stuff I'm talking about is for stored procedures, not regular usage. wink

No probs. Thanks for putting time into trying to sort this. It is greatly appreciated. smile

1,589

(38 replies, posted in PunBB 1.2 bug reports)

Just given that new code a whirl. Still throwing an error. Pgsql log line is below. Just incase it's needed, btw, the version of pgsql running on this machine is 8.2.4.

ERROR:  syntax error at or near "IF" at character 1
STATEMENT:  IF EXISTS(SELECT 1 FROM punbb_online WHERE user_id = 3) THEN UPDATE punbb_online SET logged=1189031054 WHERE user_id=3 ELSE INSERT INTO punbb_online (user_id, ident, logged) VALUES(3, 'Matt', 1189031054) END IF


Thanks again. smile

1,590

(38 replies, posted in PunBB 1.2 bug reports)

Apologies. Missed that completely. I'm having a diddle on a test db/forum at the mo, so I'll try adapting it with those. Must admit, I'm naff at sql personally. big_smile

1,591

(38 replies, posted in PunBB 1.2 bug reports)

Know what you mean. It's somewhat confusing. big_smile I've been having a look, and one doc I saw seems to suggest it follows a command but goes before the condition, (if that's the correct way of phrasing it)?

http://developer.postgresql.org/pgdocs/ … table.html

1,592

(38 replies, posted in PunBB 1.2 bug reports)

Just given it a quick test. It bombs out with the 'Unable to insert user into online list' error message with the pgsql clause added.

This is from the pgsql log:

ERROR:  syntax error at or near "IF" at character 1
STATEMENT:  IF EXISTS(SELECT 1 FROM punbb_online WHERE user_id = 3) UPDATE punbb_online SET logged=1189015769 WHERE user_id=3 ELSE INSERT INTO punbb_online (user_id, ident, logged) VALUES(3, 'Matt', 1189015769)


Edit: Forgot to add, (even though it's probably obvious), that the message only appears once logged in.

1,593

(38 replies, posted in PunBB 1.2 bug reports)

Cheers. I'll update the code later today for testing. Thanks ever so much for putting your time into this problem. smile smile Just one question if I may? Are there any circumstances/conditions that may cause this condition, for testing it with? It hasn't reared it's head for awhile, so wondered if I may be able to instigate the problem in any way?

1,594

(8 replies, posted in PunBB 1.2 troubleshooting)

Papillon wrote:

Oh! I see!
But still, that gotta be fixed!

Thank you smile.

Seriously, if you manage to find out what criteria the likes of AOL/Gmail/Hotmail use, (other than random can't be arsed'ness), to filter e-mails, you'll have succeeded where no other has. big_smile big_smile One thing to check first, however, are the basics  for smooth operation on a correctly configured smtp/MX server, i.e:

1) Do you have a PTR record for the outbound smtp server?

2) Are you using an A record and not a CNAME for the outbound smtp server?

3) Is the DNS correctly configured in all other regards for the outbound server?

DNS errors or misconfigurations are one thing that will lead to your mail being dumped/quarantined in no short fashion by a lot of MX servers. The CNAME part is more essential in MX records, but it is best practise not used on both MX/outbound smtp servers.

Aye. It's no fun this conversion thing is it? big_smile Used all the info from the archives, but some points above weren't mentioned in previous discussions. Hopefully, might make it easier for people in the meantime until the script appears. smile

Just been running through the Mysql bit as well. Pgsql is far easier to convert. big_smile Few notes for future reference, though.

Firstly, doing a dump of the db to flatfile, run the iconv command above on the dump, and then secondly it needs this running on the dump file:

sed -e 's/latin1/utf8/g' < [converted_file] > [converted_utf8]

That will change all the, (in this example), latin1_swedish_ci entries to utf8_general_ci entries in the dbfile.

To create a utf8 db with Mysql, the command is:

mysql -u [db_username] -p --execute="CREATE DATABASE [db_name] CHARACTER SET utf8 COLLATE utf8_general_ci;"

It can be verified that the collation and character sets are correct by using mysql to connect to the database then issuing the commands:

show variables like "character_set_database";
show variables like "collation_database";

Plus, if all the databases are going to be in utf8 format, the 'SET NAMES' addition to the common_db.php file can be mooted by running mysqld with the following options to start the server:

/[path_to]/mysqld\
        --character-set-server=utf8\
        --collation-server=utf8_general_ci\
        --skip-character-set-client-handshake

That should make Mysql run using utf8 as default, and will make it ignore the client encoding requested/sent by the client. I have one programme using Mysql here which I'm going to adapt to use utf8, so I'll let you know when I've tested it if anything fails spectacularly. big_smile

Smartys wrote:

I would set it

Cheers. smile

Just another reference question on this one. The mb_string support in php. Does the setting in the ini file:

mbstring.internal_encoding

need changing to UTF-8 too, or leaving at the system default, i.e: ISO-8859-1?

Smartys wrote:

Convert the database content to UTF-8 and I think you're good to go smile

Cheers Smartys. Did the conversion, (only one db required conversion due to it having characters the UTF8 format wasn't happy with), and it all appears to be working fine now. smile

Thought I'd just pop some further info up on this too, incase it's ever useful in the future for someone else.

Firstly, don't make the stupid mistake I wasted two hours upon. big_smile Mysql, if I remember correctly, just dumps a text version of the database when you do a dump. Pgsql, however, allows you to select several formats for the dump. Guess who didn't do a plaintext flatfile when he should have. big_smile The command for pgsql, to do a db dump which will allow it to be converted is:

pg_dump [database_name] > [output_file]

If one uses the -Fc option to pg_dump, it won't be suitable for conversion. To reload the file after conversion, the command is:

psql -d  [database_name] < [converted_file]

Running the command:

iconv -f ISO-8859-1 -t UTF-8  [output_file] > [converted_file]

will change the formatting of the characters, (in the above example from is0-8859-1), to utf8.



Also, the SET NAMES addition to the common_db.php file isn't required for Pgsql. It will already return the client_encoding type depending upon the database type, so it's appears to be a moot requirement with Pgsql. The command:

$db->query("SET NAMES 'UTF8'");

is an alias for, (to give it the true Pgsql syntax):

$db->query("SET 'client_encoding' TO 'UTF8'");

Finally, to create a utf8 db in Pgsql, (the default is SQL_ASCII), the command is:

createdb -E UTF8 -O [database_owner] [database_name]

Hope this is of some help. smile

Just checking on this. Was going to convert to UTF8 as I'm in the process of reinstalling the forum server. smile Doing the following is all that is required on an English only database? Or is there something else I've missed? This is a postgresql db, btw, so the database types I've created as UTF8 in preparation. PHP has also been compiled with mb_strings.

In include/dblayer/common_db.php after this line:

$db = new DBLayer($db_host, $db_username, $db_password, $db_name, $db_prefix, $p_connect);

add this line:

$db->query("SET NAMES 'UTF8'");

In LANG/common.php, altering the lang_encoding line to:

lang_encoding' => 'utf-8'

Have I found everything I need to do? (Other than changing any specific iso-8859-1 entries in other files to utf8).


Cheers,

Matt