boen_robot

A google search of the error message leads to this. If you're using Windows 7, you may want to run the command prompt as an Administrator before executing that command.

When I say "good" above, I mean "valid" - it's by an authorized IP, contains a valid Host header, points to an existing file or matches a rewrite rule."Bad" is everything else. Requests from unauthorized IPs, unknown Host header, not existent file, forbidden file, no matching rewrite rule, etc.Whether the request was "bad" as in "malicious" or "bad" as in "accidental mistype" is something the PHP script could try to determine... or not.

He won't like me anyway... I have a (healthy) cat.

If you redirect both good and bad requests to the same file, yes. If you have a dedicated file for bad requests, you don't need that check, since you already know it's a bad request. The only thing left for the script to do is figure out why is this a bad request, and act accordingly.

I've been on both sides of the typing thing too. Don't worry .

No... it actually runs the PHP file itself (which PHP file? The one you specify when you configure those), but within the PHP file, your super globals ($_SERVER, $_GET, $_POST, etc.) are populated with what would've been received if this was a real file.The output looks like whatever you make that PHP script output.

Using mod_rewrite or the ErrorDocument directive, you can redirect all requests (or all requests that are not to known files) to a single PHP file. From within this PHP file, $_SERVER['REQUEST_URI'] will contain the full URI that the file was accessed with. Other $_SERVER variables contain some more specific data that you could analyze.

But you won't be writing any ban if you just place the automated rules once. The only thing you'll be adding are new referrer entries. And since only a few particular refers are the problem, you could match that to any ".ru", ".md", etc. (other than google.* that is) and ban any IP that contains such a refer. Simple, effective, automated, and allows legitimate traffic in.

But that's kind of my point - instead of nuking whole countries, you can permanently disable known malicious hosts and attackers, and thus keep your logs clear, while still allowing humans from those countries. This would also be a more efficient option BTW.If it troubles you that a spam IP might become a legitimate one (which doesn't seem to be the case, but still...), you could make a timeout for each entry, and periodically unban expired entries.

How do you know you have legitimate access if you've banned all traffic?

As someone from a small damned country that most sites obviously don't get much traffic from, I must say I'm offended on behalf of all legitimate users from the countries you've banned.I mean, if you have all the tools to dynamically ban attackers, you're just being lazy by not using them.For your referrer problem, simply ban anyone with a known bad referrer. mod_rewrite can match even that in a rule.Side note, you do realize certain bad people (*caugh*na*caught*zi) use similar logic when talking about people, right? It's a slippery slope.... sort of.

Why don't you ban just the offenders' IPs? In fact, why don't you configure your server to redirect known malicious requests like that to a PHP file that would automatically add the offender's IP to the list of banned IPs?

There should be only one server and one client running, and the server must be started first.If you try to run two servers, the second one should fail to receive any messages.If you try to run two clients, the second one will wait a few seconds, and fail unless the server is finished with the previous client in that time.What is the rest of the message anyway?Anyway... the reason you see those is that some socket errors provide error messages and numbers from the OS itself. When there are no such things in the particular exception, you just see empty strings.

$_GET and $_POST don't really "do" anything. They just contain data. You are supposed to make them appear to do something by checking them and making PHP act accordingly.$_GET contains data from the URL's query string. If you call the PHP file like index.php?id=avalue&somethingElse=anotherValue then $_GET will look like the equivalent of $_GET = array('id' => 'avalue', 'somethingElse' => 'anotherValue'); It's a similar thing with $_POST, but instead of the URL, it's the request body. If you have a form like: <form method="post" action="processor.php"><input name="id" value="avalue" /><input name="somethingElse" value="anotherValue" />...</form> Then submitting this form will result in processor.php receiving a $_POST that has contents equivalent to: $_POST = array('id' => 'avalue', 'somethingElse' => 'anotherValue');

That is what the above is doing. The server program can be on a different machine than the client.Both of them can be made to send and receive stuff entered by a user rather than "hard coded" stuff. They could also be made to receive stuff of variable length rather than a constant one. I'm keeping it a constant hard coded stuff for simplicity's sake.But if you want to observe a more real app... here's one that users interact with from the command line, although it still demands constant length messages:The server: <?phpnamespace PEAR2\Net\Transmitter;require_once 'PEAR2/Net/Transmitter/Autoload.php';$server = stream_socket_server('tcp://127.0.0.1:6666');echo "Server started...\n";while (true) { try { $conn = new TcpServerConnection($server, -1); echo "[[New peer]]\n"; while ('DONE' !== $message = $conn->receive(4)) { echo $message, "\n"; $conn->send(trim(fgets(STDIN))); } echo "[[Peer is gone]]\n"; } catch (Exception $e) { echo $e; }} The client: <?phpnamespace PEAR2\Net\Transmitter;require_once 'PEAR2/Net/Transmitter/Autoload.php';$c = new TcpClient('127.0.0.1', 6666);echo "[[Connected...]]\n";while (true) { $message = trim(fgets(STDIN)); $c->send($message); if ('DONE' === $message) { break; } echo $c->receive(2), "\n";} Run BOTH the server and the client from the command line. First the server, then the client.Then, type 4 letters from the client and hit enter. You'll see them appear in the server. From the server, type 2 letters and hit enter, and you'll see them appear on the client. You can go back and forth as you please, just as long as you keep 4 letters from clients, and 2 letters back. You can type "DONE" from the client to disconnect the client from the server.To implement variable length messages, you need to invent your own "protocol" (as in "algorithm") that would somehow specify how the length of each message is determined.In the HTTP protocol for example, the client/server first receives everything, byte by byte, up to "\n\n" (or some hardcoded limit), and expects to find "Content-Length: XX" within what it has received. From there, it reads the number of bytes Content-Length says.In some simpler protocols, the first byte is the length that the client/server should then receive.In some more complex protocols, the client and server have different means of calculating the length from the other peer (e.g. constant length messages from client to server, "first byte" length messages from server to client).

And does the URL have "id" in it?Let's try some debugging. At the top, right before the first if, place: var_dump($_GET, $_POST); And see what you're getting.

You're using both $_GET['id'] and $_POST['id'] on the line if((isset($_GET['id'])) && (is_numeric($_POST['id']))){ Changes are only one of them is defined, which is why you get the notice. Pick the correct one, and replace all references to the other with it.Also, }elseif ((isset($_POST['id'])) && (is_numeric($_POST['id']))){ $query = "SELECT * FROM news WHERE id='$id'"; $result = mysqli_query($con, $query); $id = $_POST['id']; The ID should be defined before the query, so: }elseif ((isset($_POST['id'])) && (is_numeric($_POST['id']))){ $id = $_POST['id']; $query = "SELECT * FROM news WHERE id='$id'"; $result = mysqli_query($con, $query); P.S. mysqli_real_escape_string()?

I can see why you're not in any way impressed though... there's no state. It doesn't feel like the server has any purpose in the whole scheme...OK, here's a slightly more complicated server: Once the server receives a "HERE" from a client, it will continue to answer "ok" to "######", until it receives "HERE" again. <?phpnamespace PEAR2\Net\Transmitter;require_once 'PEAR2/Net/Transmitter/Autoload.php';$server = stream_socket_server('tcp://127.0.0.1:6666');$hasIt = false;while (true) { try { $conn = new TcpServerConnection($server, -1); while ('DONE' !== $message = $conn->receive(4)) { switch ($message) { case '######': $conn->send($hasIt ? 'ok' : 'no'); break; case 'OPPS': $conn->send('oh'); break; case 'HERE': $hasIt = !$hasIt; $conn->send('ty'); break; case 'KILL': break 3; default: $conn->send('??'); } } } catch (Exception $e) { echo $e; }} And with just a slight altering of the client... <?phpnamespace PEAR2\Net\Transmitter;require_once 'PEAR2/Net/Transmitter/Autoload.php';$c = new TcpClient('127.0.0.1', 6666);$c->send('######');echo $c->receive(2), "\n";$c->send('OPPS');echo $c->receive(2), "\n";$c->send('HERE');echo $c->receive(2), "\n";$c->send('DONE'); ...now the client will first output "no oh ty", then, at the next request, "ok oh ty", then back to "no oh ty" and so forth. NOW you can clearly see that the server is "alive" in that it remembers what it was once told in a previous connection, and it acts accordingly.

That's exactly what's supposed to happen.Like I said, there is no dialogue between clients, because there is no way with PHP (on Windows) you can have two clients connected to the same server at the same time.If you take another look at the client, there is a sort of dialogue between the one client and the one server though: <?phpnamespace PEAR2\Net\Transmitter;require_once 'PEAR2/Net/Transmitter/Autoload.php';$c = new TcpClient('127.0.0.1', 6666);$c->send('######');echo $c->receive(2), "\n";$c->send('OPPS');echo $c->receive(2), "\n";$c->send('######');echo $c->receive(2), "\n";$c->send('DONE'); Every "send" line is what the client says, and every "echo" line reflects what the server has answered. THAT is the dialogue. Change the argument of some send() calls to a different 4 letter word (like "HERE" for example), and observe the new answers.Or look at the server, and adjust the reactions in the switch as you want them.

You mean if $phone is a string, regardless of whether it matches the regular expression(s) or not?Yes, $phone is always a string. In this case, a string containing decimal numbers, and nothing more. If there's nothing to be replaced, $phone will be the same as the input (in this case $_POST['phone']).

THERE! This is what I wanted to see all along. Was it that hard? Did we had to go over all the drama?Anyway... now that we have that covered... see the code again:document.getElementById("myP") getElementById wants you to specify the value of an ID, and then it gets the element with that ID. Like you said, the value of an ID is something you set.So: "myP" is simply the value of an ID that someone chose to specify. For this code to work, somewhere in the HTML document, there needs to be an element with "myP" as its ID. If you don't have an element with such an ID, you can change "myP" into the ID of another element that you do have.

Start "aa.php"... leave it there. It is supposed not to give you any response, and just hang in there running.While it is running, from a browser, start "bb.php".

Oh... but I believe things have changed in a way (the "food thief" reference was not applicable until very recently) . Now if only Eduard sees through it, we may have progress.

Khm... I've asked you before, and I'll ask you again. And I hope you're now ready to prove you know this, by answering the following question:Is the value of a class (or ID) something you define or something HTML asks of you?Don't be the food thief! Cooperate!

Because PHP is loosely typed, and because of that, a completely valid string may be converted to a boolean false, thus causing the loop to end prematurely.Consider for example if you've named a folder "0". That is converted to a boolean false.