Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> NukeSentinel™ Enhancement Requests
Author Message
steve1
Regular
Regular


Joined: Dec 26, 2003
Posts: 50

PostPosted: Wed Aug 03, 2005 2:05 pm Reply with quote

I have some recommendations for future versions (otherwise excellent product!):

-do NOT use stristr -- you kill all php4 installs, just implement a stristr_clone function like phpnuke 7.7 does... or just use strstr(strtolower(...)) not too much more typing, is it.

-do not put `` around table names. Reason: cannot include a db prefix if one does that. I have moved my sentinel tables to its own db, and this has hampered my effort.
 
View user's profile Send private message
Raven
Site Admin/Owner


Joined: Aug 27, 2002
Posts: 17077

PostPosted: Wed Aug 03, 2005 3:42 pm Reply with quote

steve1 wrote:
I have some recommendations for future versions (otherwise excellent product!):

-do NOT use stristr -- you kill all php4 installs, just implement a stristr_clone function like phpnuke 7.7 does... or just use strstr(strtolower(...)) not too much more typing, is it.

-do not put `` around table names. Reason: cannot include a db prefix if one does that. I have moved my sentinel tables to its own db, and this has hampered my effort.

-do NOT use stristr -- you kill all php4 installs
Please explain as I have never heard of this and I have been using PHP for many years and NukeSentinel since day one.

-do not put `` around table names.
We have to as that's the only way to get MySQL to recognize _ in database and table names at the same time. So, there has to be a compromise. Please give an example of the issue you are having.
 
View user's profile Send private message
steve1
PostPosted: Wed Aug 03, 2005 3:49 pm Reply with quote

Raven wrote:
steve1 wrote:
I have some recommendations for future versions (otherwise excellent product!):

-do NOT use stristr -- you kill all php4 installs, just implement a stristr_clone function like phpnuke 7.7 does... or just use strstr(strtolower(...)) not too much more typing, is it.

-do not put `` around table names. Reason: cannot include a db prefix if one does that. I have moved my sentinel tables to its own db, and this has hampered my effort.

-do NOT use stristr -- you kill all php4 installs
Please explain as I have never heard of this and I have been using PHP for many years and NukeSentinel since day one.

-do not put `` around table names.
We have to as that's the only way to get MySQL to recognize _ in database and table names at the same time. So, there has to be a compromise. Please give an example of the issue you are having.


stristr: SORRY, upon visiting Only registered users can see links on this board! Get registered or login! realized that it works in php4 as well. I thought it did not. Sorry again.

What I did was move the tables to another db, call it ('sentinel' db). I do that since I run multiple nukes on the same box, and one to ban people only once.

So I manipulate $prefix to include db name. This does not work `sentin.some_table`. This works sentin.`some_table`.

I did not realize you need `` to make table names work. In any case, I worked around the problem by doing a "USE sentin" before entering sentinel code, so that all db references are referencing that code.

steve
 
Raven
PostPosted: Wed Aug 03, 2005 3:58 pm Reply with quote

Thanks for the explanations. especially on #1 Laughing

On the other one, now I see your issue. If I remember right, what happens is certain hosts use db_.table and that trailing _ causes problems. I could be remembering wrong but it seems that is the issue.
 
BobMarion
Former Admin in Good Standing


Joined: Oct 30, 2002
Posts: 1037
Location: RedNeck Land (known as Kentucky)

PostPosted: Thu Aug 04, 2005 9:51 am Reply with quote

If you want to set a dbname along with the table name you can do something like:
Code:
$db->sql_query("INSERT INTO `$yourdbname`.`".$prefix."_nsnst_tracked_ips` (`user_id`, `username`, `date`, `ip_addr`, `page`, `user_agent`, `x_forward_for`, `client_ip`, `remote_addr`, `remote_port`, `request_method`, `c2c`) VALUES ('".$nsnst_const['ban_user_id']."', '$ban_username2', '".$nsnst_const['ban_time']."', '".$nsnst_const['remote_ip']."', '$pg', '$user_agent', '".$nsnst_const['forward_ip']."', '".$nsnst_const['client_ip']."', '".$nsnst_const['remote_addr']."', '".$nsnst_const['remote_port']."', '".$nsnst_const['request_method']."', '$c2c')");


I've done this a few times for select users and it works well. The other option is to make copies of the db directory files and create a $db2 var like:
Code:
$db2->sql_query("INSERT INTO `".$prefix."_nsnst_tracked_ips` (`user_id`, `username`, `date`, `ip_addr`, `page`, `user_agent`, `x_forward_for`, `client_ip`, `remote_addr`, `remote_port`, `request_method`, `c2c`) VALUES ('".$nsnst_const['ban_user_id']."', '$ban_username2', '".$nsnst_const['ban_time']."', '".$nsnst_const['remote_ip']."', '$pg', '$user_agent', '".$nsnst_const['forward_ip']."', '".$nsnst_const['client_ip']."', '".$nsnst_const['remote_addr']."', '".$nsnst_const['remote_port']."', '".$nsnst_const['request_method']."', '$c2c')");


Either of the above work, I prefer the second since coping the db directory files is easy and once you do it you can search and replace $db with $db2 easily.

_________________
Bob Marion
Codito Ergo Sum
Only registered users can see links on this board! Get registered or login! 
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> NukeSentinel™ Enhancement Requests

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©