Re: [twsocket] TWSocket transliterating tabs to spaces (nevermind)
Hello: I have updated the Wiki to include an explanation of the LineEdit property. I must admit that I didn't really pay attention to what it did, and thought it was only transliterating backspaces. Since I was testing my server by telnetting from a terminal, this seemed like a good idea. I think, however, that tab padding should be a function of the display and not the transport, but I don't object it being part of the component as long as it is False by default (which seems to have been the intention). dZ. On Dec 3, 2007, at 16:37, Arno Garrels wrote: Arno Garrels wrote: be added a line FLineMode := False; FLineEdit := False; of course! (AV due to the second beer). -- Arno Garrels -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Webserver only with local connections
I have already told you the best way. Make the listening IP 127.0.0.1 . On 12/4/07, George [EMAIL PROTECTED] wrote: Hello, I created a THttpServer that is used as a middleware between my delphi app and a flash application. I want to make sure that only me and flash will communicate each other so I want to restrict connections from outside internet or local IPs. What's the safest way to check it? Any piece of code is welcomed. Thanks George -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
[twsocket] Webserver only with local connections
Hello, I created a THttpServer that is used as a middleware between my delphi app and a flash application. I want to make sure that only me and flash will communicate each other so I want to restrict connections from outside internet or local IPs. What's the safest way to check it? Any piece of code is welcomed. Thanks George -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] Webserver only with local connections
George, I think Hoby's response is excellent, but I wanted to add a few suggestions based on my interpretation of your problem. 1. If the source address of each of the hosts that will communicate is known, then you can check for this using the GetPeerAddr method from within the SessionAvailable method of TWSocket (I believe this is exposed in HttpCli as the OnClientConnect event), and as Hoby suggested, abort the connection if the address does not match. Obviously, this will bind your application to those specific addresses, so if they ever changed you'll need to make sure to update the validation values. Also, as Hoby mentioned, you must bear in mind that the source IP address can be spoofed, so depending on the criticality or exposure of your application, you may not want to trust it. 2. Authenticate the incoming request by using one of the common mechanisms supported by HttpCli. This still means that the connection needs to be accepted, and actively rejected if it failed authentication. One last note: Under no circumstances trust any information available on the HTTP request/response header for validation or authenticity (IP address, referrer, content-type, etc.); these are very trivial to forge. For most HTTP appliations, this is normally not a problem, as long as they do not expect any of those values to contain critical information that could affect the behaviour of the system. -dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html --- Original Message --- From: Hoby Smith[mailto:[EMAIL PROTECTED] Sent: 12/4/2007 12:05:56 PM To : twsocket@elists.org Cc : Subject : RE: Re: [twsocket] Webserver only with local connections George... Fundamentally, there are really only two ways to constrain inbound connections regarding client identification. As I am sure you are aware, keep in mind that neither TCP nor HTTP have any built in mechanisms for facilitating client identification or rejecting connections based on any rules. As a result, it is irrelevant what address / port you listen on, as TCP will always attempt to allow the connection initially, unless a firewall or something else between the host and server prevents the process. It is up to you then to reject any unwanted connect attempts at some point. Given this, you must address the issue in either or both of the following areas: 1. Client origin or source of connection If you wish, you may determine the client's origin and reject the connection based on that origin. The TWSocket components give you this ability at the session level. The standard TCP stack has no mechanism to do this until after the session is actually arbitrated, so by default you must accept the connect (at least partially into the cycle), then reject the connection, once you have determined that you wish to do so. So, if you wanted to constrain the source address of the client to a local or specific address only, you could provide some functionality in the OnClientConnect event that determines the connecting source address and rejects the ones you don't want, such as if it is not in the local address space. Bear in mind that the local address space could originate from the local loopback (127.0.0.1), as well as one of the local NIC addresses as well. For example, you could use, TMyHttpConnection(Client).GetPeerAddr, to get the client's address and then determine if you want to disconnect it. You would have to provide this logic and any rules as you need. Also, bear in mind that the source address can be compromised through various attacks. PPTP and other forms of tunneling attempt to prevent those kinds of issues (such as with VPNs implementations). 2. Some form of secure authentication that should be at least moderately trustable. If I understand your need correctly, you are saying that you DO want to allow connections from other IP subnets, you just want to know if they are from you or something else. To accomplish this, you need to support some form of authentication, because there is NO inherent ability in TCP or HTTP to tell you this. This is what you are really looking for. Regardless of the source of origin, you are really trying to ask the question, Is this me or someone else? Right? If so, the only solution is to use some form of authentication to determine this. I personally don't use HTTP much because it is so weak in this regard; in that, it has no native ability to support authentication. As a result, you must address authentication very high up the stack, on top of protocols that understand nothing about security or authentication. However, there are several mechanisms for performing authentication over HTTP. I would suggest that you look at the ICS demo app WebServ. It appears to be handling the authentication you are looking for and should have the code examples you are looking for. Then, after you successfully authenticate the client, the next challenge comes in
Re: [twsocket] Webserver only with local connections
Great additional info, dz. Thanks... Hoby :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, December 04, 2007 10:25 AM To: twsocket@elists.org Subject: Re: [twsocket] Webserver only with local connections George, I think Hoby's response is excellent, but I wanted to add a few suggestions based on my interpretation of your problem. 1. If the source address of each of the hosts that will communicate is known, then you can check for this using the GetPeerAddr method from within the SessionAvailable method of TWSocket (I believe this is exposed in HttpCli as the OnClientConnect event), and as Hoby suggested, abort the connection if the address does not match. Obviously, this will bind your application to those specific addresses, so if they ever changed you'll need to make sure to update the validation values. Also, as Hoby mentioned, you must bear in mind that the source IP address can be spoofed, so depending on the criticality or exposure of your application, you may not want to trust it. 2. Authenticate the incoming request by using one of the common mechanisms supported by HttpCli. This still means that the connection needs to be accepted, and actively rejected if it failed authentication. One last note: Under no circumstances trust any information available on the HTTP request/response header for validation or authenticity (IP address, referrer, content-type, etc.); these are very trivial to forge. For most HTTP appliations, this is normally not a problem, as long as they do not expect any of those values to contain critical information that could affect the behaviour of the system. -dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html --- Original Message --- From: Hoby Smith[mailto:[EMAIL PROTECTED] Sent: 12/4/2007 12:05:56 PM To : twsocket@elists.org Cc : Subject : RE: Re: [twsocket] Webserver only with local connections George... Fundamentally, there are really only two ways to constrain inbound connections regarding client identification. As I am sure you are aware, keep in mind that neither TCP nor HTTP have any built in mechanisms for facilitating client identification or rejecting connections based on any rules. As a result, it is irrelevant what address / port you listen on, as TCP will always attempt to allow the connection initially, unless a firewall or something else between the host and server prevents the process. It is up to you then to reject any unwanted connect attempts at some point. Given this, you must address the issue in either or both of the following areas: 1. Client origin or source of connection If you wish, you may determine the client's origin and reject the connection based on that origin. The TWSocket components give you this ability at the session level. The standard TCP stack has no mechanism to do this until after the session is actually arbitrated, so by default you must accept the connect (at least partially into the cycle), then reject the connection, once you have determined that you wish to do so. So, if you wanted to constrain the source address of the client to a local or specific address only, you could provide some functionality in the OnClientConnect event that determines the connecting source address and rejects the ones you don't want, such as if it is not in the local address space. Bear in mind that the local address space could originate from the local loopback (127.0.0.1), as well as one of the local NIC addresses as well. For example, you could use, TMyHttpConnection(Client).GetPeerAddr, to get the client's address and then determine if you want to disconnect it. You would have to provide this logic and any rules as you need. Also, bear in mind that the source address can be compromised through various attacks. PPTP and other forms of tunneling attempt to prevent those kinds of issues (such as with VPNs implementations). 2. Some form of secure authentication that should be at least moderately trustable. If I understand your need correctly, you are saying that you DO want to allow connections from other IP subnets, you just want to know if they are from you or something else. To accomplish this, you need to support some form of authentication, because there is NO inherent ability in TCP or HTTP to tell you this. This is what you are really looking for. Regardless of the source of origin, you are really trying to ask the question, Is this me or someone else? Right? If so, the only solution is to use some form of authentication to determine this. I personally don't use HTTP much because it is so weak in this regard; in that, it has no native ability to support authentication. As a result, you must address authentication very high up the stack, on top of protocols that understand nothing about security or authentication. However, there are several mechanisms for performing
Re: [twsocket] Webserver only with local connections
Hoby Smith wrote: [Big snip] For example, you could use, TMyHttpConnection(Client).GetPeerAddr, to get the client's address and then determine if you want to disconnect it. You would have to provide this logic and any rules as you need. There are helper functions available in OverbyteIcsWinsock2.pas to get the list of interfaces including loopback and also a function to check whether an IP is in current subnet. -- Arno Garrels [Big snip] -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ASyncReceive and wsoNoReceiveLoop
Hi Arno, Thanks for the insight. More questions below: Arno Garrels wrote: Jake Traynham wrote: So, it seems that for every time ASyncReceive looped, there would still be a message (FD_Read??) being put in the queue to call it again, which would call my DataAvailable event again, but there wouldn't be any data to read because ASyncReceive had already looped to get all the data. That's correct, it's the call to WSocket_Synchronized_ioctlsocket() with option FIONREAD that causes winsock to send the extra FD_READ message. So nothing is corrupted, simply add wsoNoReceiveLoop to the options to get rid of that behaviour. Winsock will always send subsequent FD_Read messages after any call to one of the receive functions if there is still data available. Okay, so let me make sure I understand correctly. I call Receive in my DataAvailable event. If I don't request the entire amount of available data, winsock automatically throws another FD_Read message in the queue? So, that means that if I'm going to read in 1024 bytes at a time, I should set wsoNoReceiveLoop so that I don't get extra calls to DataAvailable. This makes sense and is what my code is currently doing. However, I would like this code to work/receive as fast as possible. The comment in the code where wsoNoReceiveLoop was introduced says that this option gives lower resource usage with really fast LAN and large transfers. Does that mean it's faster, or just uses less memory? Would it be faster to read in all available data in each call to my DataAvailable event (which, if I understand correctly would not trigger the extra FD_Read events)? If so, what would be the best approach to that? Seems to me there would be three options: 1. Use GetRcvdCount to determine how much data Receive can return and read in that much data. (There is a comment in the code that says this function can't be trusted on NT) 2. When I call Receive, specify a large enough buffer to read in whatever might be there. I'm currently using a 1024 byte buffer. Would increasing that to something over 1460 be sufficient? Or would winsock buffer the data in the background while I'm processing data and send me a chunk of data much larger than what can fit in an ethernet packet? 3. Put a loop in my DataAvailable event that will do a Receive until I get -1 back. This would probably be the easiest to implement for me. All in all, speed is my main interest here. I want to read in all the data the server is sending me as fast as possible. Thanks for any pointers you or anyone else on the list can give me. Jake -- Jake Traynham Owner, CNS Plug-ins http://www.cnsplug-ins.com/ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ASyncReceive and wsoNoReceiveLoop
Hello Jake, However, I would like this code to work/receive as fast as possible. The comment in the code where wsoNoReceiveLoop was introduced says that this option gives lower resource usage with really fast LAN and large transfers. Does that mean it's faster, or just uses less memory? In fact it is a little slower when you set wsoNoReceiveLoop. 1. Use GetRcvdCount to determine how much data Receive can return and read in that much data. (There is a comment in the code that says this function can't be trusted on NT) Correcect it is unreliable on NT. I never used it because of this but never used it in later OS also. So I dont know if it is still unreliable in other OS. Or would winsock buffer the data in the background while I'm processing data and send me a chunk of data much larger than what can fit in an ethernet packet? Yes, it is depending the sending speed (lan speed), receiving speed. 3. Put a loop in my DataAvailable event that will do a Receive until I get -1 back. This would probably be the easiest to implement for me. No never do that. Don't set wsoReceiveLoop. If something is still (or again) in receiving winsock buffer when you leave OnDataAvailable then it will trigger again in a loop. All in all, speed is my main interest here. I want to read in all the data the server is sending me as fast as possible. - if possible move the data direcly where it belong, not copy it first in a buffer as you do now. If you have to buffer it in between for some reason make it as large as possible (make a little test case to see how large receiving packets will be in a real world test). - if you move direcly where it belong then you have to receive only what you need of course. but no worry OnDataAvailable will trigger again immediatly. --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Tuesday, December 4, 2007, 20:31, Jake Traynham wrote: Hi Arno, Thanks for the insight. More questions below: Arno Garrels wrote: Jake Traynham wrote: So, it seems that for every time ASyncReceive looped, there would still be a message (FD_Read??) being put in the queue to call it again, which would call my DataAvailable event again, but there wouldn't be any data to read because ASyncReceive had already looped to get all the data. That's correct, it's the call to WSocket_Synchronized_ioctlsocket() with option FIONREAD that causes winsock to send the extra FD_READ message. So nothing is corrupted, simply add wsoNoReceiveLoop to the options to get rid of that behaviour. Winsock will always send subsequent FD_Read messages after any call to one of the receive functions if there is still data available. Okay, so let me make sure I understand correctly. I call Receive in my DataAvailable event. If I don't request the entire amount of available data, winsock automatically throws another FD_Read message in the queue? So, that means that if I'm going to read in 1024 bytes at a time, I should set wsoNoReceiveLoop so that I don't get extra calls to DataAvailable. This makes sense and is what my code is currently doing. However, I would like this code to work/receive as fast as possible. The comment in the code where wsoNoReceiveLoop was introduced says that this option gives lower resource usage with really fast LAN and large transfers. Does that mean it's faster, or just uses less memory? Would it be faster to read in all available data in each call to my DataAvailable event (which, if I understand correctly would not trigger the extra FD_Read events)? If so, what would be the best approach to that? Seems to me there would be three options: 1. Use GetRcvdCount to determine how much data Receive can return and read in that much data. (There is a comment in the code that says this function can't be trusted on NT) 2. When I call Receive, specify a large enough buffer to read in whatever might be there. I'm currently using a 1024 byte buffer. Would increasing that to something over 1460 be sufficient? Or would winsock buffer the data in the background while I'm processing data and send me a chunk of data much larger than what can fit in an ethernet packet? 3. Put a loop in my DataAvailable event that will do a Receive until I get -1 back. This would probably be the easiest to implement for me. All in all, speed is my main interest here. I want to read in all the data the server is sending me as fast as possible. Thanks for any pointers you or anyone else on the list can give me. Jake -- Jake Traynham Owner, CNS Plug-ins http://www.cnsplug-ins.com/ -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] ASyncReceive and wsoNoReceiveLoop
No never do that. Don't set wsoReceiveLoop. If something is still (or again) in receiving winsock buffer when you leave OnDataAvailable then it will trigger again in a loop. I don't agree with this. I had troubles with a httpserver crashing when large files were transmitted on a high speed connection. With the help of François, it was solved by adding wsNoReceiveLoop. Paul -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
