Revision history for RegisterUserIpAddress
Revision [23124]
Last edited on 2016-05-20 07:38:46 by WazoO [Replaces old-style internal links with new pipe-split links.]Additions:
//Part of this is installed as a [[WikkaBetaFeatures | beta feature]] on this server.//
>>Since we already have a **beta** **[[RegisterAction | register action]]** on this server, this now records the user's IP address the same way:
[""<a href="RegisterUserIpAddress#src1" id="ref1">1</a>""] [[http://docs.hp.com/en/5990-7278/ch06s02.html | IPv6 Address Formats]]
>>Since we already have a **beta** **[[RegisterAction | register action]]** on this server, this now records the user's IP address the same way:
[""<a href="RegisterUserIpAddress#src1" id="ref1">1</a>""] [[http://docs.hp.com/en/5990-7278/ch06s02.html | IPv6 Address Formats]]
Deletions:
>>Since we already have a **beta** **[[RegisterAction register action]]** on this server, this now records the user's IP address the same way:
[""<a href="RegisterUserIpAddress#src1" id="ref1">1</a>""] [[http://docs.hp.com/en/5990-7278/ch06s02.html IPv6 Address Formats]]
No Differences
Additions:
~-TrackIPaddressMod
Additions:
~''Only today, three spam comments were added (to two pages); all three had identical content and two were made within minutes of each other - suggesting they were made by the same spammer - but all three had different origin addresses, making it quite likely the spammer was using trojaned machines (and possibly a script). All three origin addresses were listed in one or more blacklists. This is a typical case where banning by IP address would **not be effective at all** while carrying the risk of hurting innocent users who are not spamming at all. --JW 2005-07-19''
Deletions:
Additions:
So don't expect these beta features to be as "polished" as most beta features are: **if** they are effective they usually require more work to make them ready for release.''
~''Only today, three spam comments were added (to two pages); all three had identical content and two were made within minutes of each other - suggesting they were made by the same spammer - but all three had different origin addresses, making it quite likely the spammer was using trojaned machines (and possibly a script). All three origin addresses were listed in one or more blacklists. This is a typical case where banning by IP address would not only be **not effective at all** while carrying the risk of hurting innocent users who are not spamming at all. --JW 2005-07-19''
~''Only today, three spam comments were added (to two pages); all three had identical content and two were made within minutes of each other - suggesting they were made by the same spammer - but all three had different origin addresses, making it quite likely the spammer was using trojaned machines (and possibly a script). All three origin addresses were listed in one or more blacklists. This is a typical case where banning by IP address would not only be **not effective at all** while carrying the risk of hurting innocent users who are not spamming at all. --JW 2005-07-19''
Deletions:
Additions:
~-SecurityModules
''The beta security and antispam features implemented on this server are usually more intended as "let's see if this is effective" than as ready-to-release features with ready-to-copy code: No need to polish code when something isn't effective as a security measure, after all - and that can only be really tested on a "live" server.
So don't expect these beta features to be as "polished" as most beta features are: **if** they are effective they usually require more work to make them ready for release.
>>This is the development page for an anti-spam (and anti-abuse) feature intended to trace IP addresses used by (registered) users; this is intended to be able to ban spamming or abusive users by IP address if necessary.::c::
''The beta security and antispam features implemented on this server are usually more intended as "let's see if this is effective" than as ready-to-release features with ready-to-copy code: No need to polish code when something isn't effective as a security measure, after all - and that can only be really tested on a "live" server.
So don't expect these beta features to be as "polished" as most beta features are: **if** they are effective they usually require more work to make them ready for release.
>>This is the development page for an anti-spam (and anti-abuse) feature intended to trace IP addresses used by (registered) users; this is intended to be able to ban spamming or abusive users by IP address if necessary.::c::
Deletions:
>>This is the development page for an anti-spam (and anti-abuse) feature intended to trace IP addresses used by registered users; this is intended to be able to ban spamming or abusive users by IP address if necessary.::c::
Additions:
Then, given the information about which IP address is used for which activity, we need the utilities to support decision-making and to action based on that decision. So two types of utilities will be needed:
~1)Utilities to gather and review data about user activity (signup, creating and editing pages, adding comments) and the IP addresses involved in each. When considering banning by IP address it will be necessary to not only look at the activities of a registered user, but also **all** activity related to the "suspect" IP address (some of which may be by unregistered users).
~1)Utilities to implement a decision to delete, disable or ban a user, either by name or by IP address. Banning by IP address should be possible either via the ##.htaccess## file or (if this is not supported) via the application itself.
Obviously, a lot still needs to be done in this respect.
//preliminary specifications to follow//
~1)Utilities to gather and review data about user activity (signup, creating and editing pages, adding comments) and the IP addresses involved in each. When considering banning by IP address it will be necessary to not only look at the activities of a registered user, but also **all** activity related to the "suspect" IP address (some of which may be by unregistered users).
~1)Utilities to implement a decision to delete, disable or ban a user, either by name or by IP address. Banning by IP address should be possible either via the ##.htaccess## file or (if this is not supported) via the application itself.
Obviously, a lot still needs to be done in this respect.
//preliminary specifications to follow//
Deletions:
//to follow//
Additions:
~-To ban an **unregistered** user, banning by IP address is the only option. Caution is necessary to make sure the user always uses the same IP address (see above).
Additions:
~-First of all, the current column added to the ##users## table should be renamed from the somewhat ambiguous ##`ipaddress`## to something more descriptive (we already have ##`signuptime`## so ##`signupipaddress`## would be a lot more descriptive) and then placed next to ##`signuptime`##. Also the size of 15 is enough for an ""IPv4"" address (nnn.nnn.nnn.nnn - (4*4)-1) but not enough to hold an ""IPv6"" address: such addresses are increasingly being used, so if we are going to add a column we'd better make sure it can actually hold **all** IP addresses. To be able to store any **""IPv6""** address a length of **39 bytes** would be needed ((8*5)-1) [""<a href="RegisterUserIpAddress#fn1" id="src1">1</a>""]. Finally, to gather information about IP addresses used, an index on this column would probably be needed as well (currently there isn't one).
~-We already store the user name for edits in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when making an edit; as with ##`signupipaddress`## in the ##users## table this should have a size of 39 bytes and be indexed. The **##edit## handler** should take care this is recorded.
~-We already store the user name for comments in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when adding a comment; as with ##`signupipaddress`## in the ##users## table this should have a size of 39 bytes and be indexed. The **##addcomment## handler** should take care this is recorded.
~-We already store the user name for edits in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when making an edit; as with ##`signupipaddress`## in the ##users## table this should have a size of 39 bytes and be indexed. The **##edit## handler** should take care this is recorded.
~-We already store the user name for comments in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when adding a comment; as with ##`signupipaddress`## in the ##users## table this should have a size of 39 bytes and be indexed. The **##addcomment## handler** should take care this is recorded.
Deletions:
~-We already store the user name for edits in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when making an edit; as with ##`signupipaddress`## in the ##users## table this should have a size of 49 bytes and be indexed. The **##edit## handler** should take care this is recorded.
~-We already store the user name for comments in the ##`user`## column; next to this we would add a new column ##`useripaddresss`## to record the ip address the user was working from when adding a comment; as with ##`signupipaddress`## in the ##users## table this should have a size of 49 bytes and be indexed. The **##addcomment## handler** should take care this is recorded.
Additions:
// made secure by applying mysql_real_escape_string() - JavaWoman 2005-07-18
"ipaddress = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."', ".
===##actions/register.php##===
>>**see also:**
~-RegisterAction
>>Since we already have a **beta** **[[RegisterAction register action]]** on this server, this now records the user's IP address the same way:
%%(php;111) // create user
// ipaddress logging as added by JsnX 20050621 (?) to usersettings.php to help combat spam
// made secure by applying mysql_real_escape_string() - JavaWoman 2005-07-18
"ipaddress = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."', ".
"password = md5('".mysql_real_escape_string($_POST['password'])."')");
"ipaddress = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."', ".
===##actions/register.php##===
>>**see also:**
~-RegisterAction
>>Since we already have a **beta** **[[RegisterAction register action]]** on this server, this now records the user's IP address the same way:
%%(php;111) // create user
// ipaddress logging as added by JsnX 20050621 (?) to usersettings.php to help combat spam
// made secure by applying mysql_real_escape_string() - JavaWoman 2005-07-18
"ipaddress = '".mysql_real_escape_string($_SERVER['REMOTE_ADDR'])."', ".
"password = md5('".mysql_real_escape_string($_POST['password'])."')");
