IWServerControllerBaseBeforeNewSession

[Lorbass]

At this point (IWServerControllerBaseBeforeNewSession) it would be interesting to prevent a response of the server.

In other words: The server does not respond and is therefore "invisible".

Can this be implemented? Or is there an adequate possibility somewhere else?

Thanks in advance for a reply on this!

[Alexandre Machado]

If you just set the vCanCreate parameter to False, IW will take care of that for you responding with the SessionOptions.HttpStatusForDeniedSessions response code, which is by default 404, the most recommended for this situation.

Code:

procedure TIWServerController.IWServerControllerBaseBeforeNewSession(
  const aUrlPath: string; aRequest: THttpRequest; out vCanCreate: Boolean);
begin
  vCanCreate := False;
end;

IMO this is the closest to "pretend that it doesn't exist" that you can get after receiving the request (because the other side, the browser, knows that your server effectively exists because it accepted a connection and the request)

[Lorbass]

You're right.
But maybe there is another event of the ServerController to prevent any response based on the request?
My goal would be to generate a timeout (ERR_CONNECTION_TIMED_OUT) for unwanted requests.

[Alexandre Machado]

I don't see how you can do this using HTTP protocol. When the browser connects to the server there are 2 possibilities: The server responds at some point or the connection is broken (and the browser detects it and knows that the connection has been broken). What you want is to deny a connection before knowing the nature of the request, which I think won't succeed. You could try to block the request/connection at a router or proxy level based on the IP of the origin.

[Lorbass]

I don't see how you can do this using HTTP protocol. When the browser connects to the server there is 2 possibilities: The server responds at some point or the connection is broken (and the browser detects it and knows that the connection has been broken). What you want is to deny a connection before knowing the nature of the request, which I think won't succeed. You could try to block the request/connection at a router or proxy level based on the IP of the origin.

Yes I know, a router/firewall is normal; but they cannot always be configured in a specialized way or are too expensive.
ServerController as an additional software-based firewall would therefore be interesting ...
Maybe sometime in the future  

[MJS@mjs.us]

>>In other words: The server does not respond and is therefore "invisible".
>>Or is there an adequate possibility somewhere else?

Outside of IW I wrote a Win32 app to maintain a list of ip's or subnets to block when needed (this could be also done inside of ServerCrontoller).  If my IW apps don't like a request and want to block it they just add the ip to an Sqlite database monitored by the Win32 app.  The Win32 app also scans my SMTP logs and looks for intrusion attempts, etc.  Once a minute the Win32 app looks for new entries and if found creates and runs a PowerShell script to add to an inbound rule of Windows Firewall that blocks the ip or subnet.  After that the server really does become invisible to the original connection. I let the blocked addresses roll off after 24 hours.  Very low tech but it seems to work.

[Alexandre Machado]

MSJ above presents a very interesting (and also simple, effective and cheap) solution for that problem.

IntraWeb internally already has all the logic to block connections based on their IP (it is used with the IWIPGeolocation classes), but at its core level (i.e. after the request has been received). It would be interesting to reject connections at the server level based on some user configurable rules

[DanBarclay]

>>In other words: The server does not respond and is therefore "invisible".
>>Or is there an adequate possibility somewhere else?

Outside of IW I wrote a Win32 app to maintain a list of ip's or subnets to block when needed (this could be also done inside of ServerCrontoller).  If my IW apps don't like a request and want to block it they just add the ip to an Sqlite database monitored by the Win32 app.  The Win32 app also scans my SMTP logs and looks for intrusion attempts, etc.  Once a minute the Win32 app looks for new entries and if found creates and runs a PowerShell script to add to an inbound rule of Windows Firewall that blocks the ip or subnet.  After that the server really does become invisible to the original connection. I let the blocked addresses roll off after 24 hours.  Very low tech but it seems to work.

Elegant.  Solid.  Great thinking.

Dan

[Alexandre Machado]

Elegant.  Solid.  Great thinking.

Dan

I agree. Simple things tend to work solidly in production and are simple to understand and maintain.

[Lorbass]

Elegant.  Solid.  Great thinking.

Dan

I agree. Simple things tend to work solidly in production and are simple to understand and maintain.

I agree with the ratings. Good work! 

We are currently proceeding more or less the same way in the ServerController. However, without Windows Firewall.