TWSocket problem on Delphi Intraweb

[qubits 20]

idk intraweb either, but looks like it's running in a browser.

wouldn't that be considered a security flaw if we could privately fire up an ssl socket and start sending data out to some other server??

 

[FPiette 383]

Quote

The only thing that makes sense to me is if maybe the window created by AllocateHWnd() was silently destroyed, but the FWinHandle variable wasn't updated to reflect that.

Using Microsoft Spy++, it is easy to see if the window created by AllocateHWnd() was silently destroyed. I tested this with the VCL application and Spy++ correctly show the invalid window handle. Display the window properties dialog and refresh that dialog periodically, then when the window handle is destroyed, Spy++ will display "Invalid Window". I cannot try with IntraWeb because I don't have that product.

Note that when the window is destroyed, the corresponding WndProc is called with WM_DESTROY (2) and WM_NCDESTROY (130) messages before the window is really destroyed and this is shown by the WndProc in the VCL test code I wrote and should be shown by the corresponding IntraWeb code.

 

Maybe IntraWeb intercept AllocateHWnd/PostMessage/WndProc and subclass the created window and then somehow break the usual win32 API behavior.

 

Edited March 11, 2022 by FPiette
Typo

[Alex7691 7]

For future readers:

 

AllocateHWnd is not thread safe and should never be used like that in any multi-threaded application (not only IntraWeb servers).

 

I'll have a look at his example out of curiosity, but this code the way it is now is not recommended, not supported and definitely won't work reliably.

 

 

 

[Baxing 0]

On 3/11/2022 at 3:04 AM, FPiette said:

You're welcome.

Whenever you get the solution, please post it here.

 

Hello FPiette,

 

I have posted a new thread in the Intraweb forum. And there are many members who have replied to the topic. If you are interested, you can read it in this link. 

 

For now, I am not able to implement ICS on IntreWeb, I am currently working on a way to implement an Indy TCP socket on IntraWeb for WebSocket Client(I have a sample code from this link) but still use ICS for a WebSecket Server.

 

And if you have any suggestions to be able to using ICS on IntraWeb please tell me.

 

Thank you

[FPiette 383]

4 hours ago, Alex7691 said:

AllocateHWnd is not thread safe and should never be used like that in any multi-threaded application (not only IntraWeb servers).

ICS has his own AllocateHWnd method that is thread safe. It make use of a critical section to protect the class registration (GetClassInfo and RegisterClass) and then use CreateWindowEx to create the handle. For those interested, look at TIcsWndHandler.AllocateHWnd in unit OverbyteIcsWndControl.

 

1 hour ago, Baxing said:

I have posted a new thread in the Intraweb forum.

This thread is full of false assertions about ICS and Windows. They say messages doesn't work in thread and that is completely wrong. Microsoft documentation says :

Quote

The system does not automatically create a message queue for each thread. Instead, the system creates a message queue only for threads that perform operations which require a message queue. If the thread creates one or more windows, a message loop must be provided; this message loop retrieves messages from the thread's message queue and dispatches them to the appropriate window procedures.

ICS is designed to work within threads. ICS make use of Windows messages which is perfectly correct to use within threads if you follow the rules (See above: Have a message pump in the thread which is not the default. A thread is like a console mode application: it has no message pump by default). ICS comes with a number of multi thread samples.

 

In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product.

 

In my first reply (March 7) I told you :

Quote

I call tell you the requirement for ICS : You need a message pump to have the events triggered. If IntraWeb lacks a message pump, you may put all your ICS stuff within a single thread having his own message pump.

IntraWeb has no message pump in their threads so as I said, put all your stuff within a single thread that you create and having his own message pump (See the samples provided with ICS).

[Alex7691 7]

Quote

ICS has his own AllocateHWnd method that is thread safe. It make use of a critical section to protect the class registration (GetClassInfo and RegisterClass) and then use CreateWindowEx to create the handle. For those interested, look at TIcsWndHandler.AllocateHWnd in unit OverbyteIcsWndControl.

I did not mention ICS at all. I'm pointing at his test case application which does not use ICS. This is a standard AllocateHWnd RTL call and it won't work reliably. That's a fact.

 

Once you mention that you patch AllocateHWnd from ICS code, are you 100% sure that your patch doesn't break anything else that IntraWeb relies on?

 

Quote

In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product.

After saying yourself that you know nothing about IntraWeb, this kind of statement is at least curious.

 

Regards

Edited March 19, 2022 by Alex7691

[Alex7691 7]

I've just tested his test application (without ICS, but the same issue will definitely happen). There is nothing wrong with IntraWeb.

 

He's using an Indy-based IntraWeb server. He creates a window handle when his application is receiving an incoming request. The Indy HTTP server spawns a worker thread which is freed afterward. The window handle is released when the thread is destroyed. Then he tries to use the same window handle in a subsequent request, from another thread (there is no guarantee that the original thread which created the window handle hasn't been destroyed).

 

This is documented here: https://docs.microsoft.com/en-us/windows/win32/procthread/terminating-a-thread

 

BTW: his example works when using Http.sys-based IntraWeb application (not Indy) because the threads are obtained from a thread pool and recycled, so the windows created in one request will be still valid in a subsequent request (although I don't recommend his way of using it at all).

 

Quote

In the IntraWeb forum, they just want to hide a problem they overlooked with IntraWeb and they want you to use their product.

Given that the application behavior is not only expected but also correct, your statement above is obviously false.

 

Regards

Edited March 19, 2022 by Alex7691

[FPiette 383]

7 hours ago, Alex7691 said:

Once you mention that you patch AllocateHWnd from ICS code, are you 100% sure that your patch doesn't break anything else that IntraWeb relies on?

ICS doesn't patch anything at all. It makes use of Windows API directly on his own. ICS register his own window class and create all his hidden windows using that class. This doesn't interfere with anything and it is perfectly respectful of Microsoft documentation.

 

5 hours ago, Alex7691 said:

I've just tested his test application

That test application is just a test to understand if IntraWeb has a message pump. Nothing more.

[Remy Lebeau 1398]

On 3/19/2022 at 5:31 AM, Alex7691 said:

BTW: his example works when using Http.sys-based IntraWeb application (not Indy) because the threads are obtained from a thread pool and recycled, so the windows created in one request will be still valid in a subsequent request

Indy supports thread-pooling in its TCP servers.  I don't use IntraWeb, so I don't know if/how that can be enabled in the context of IntraWeb, though.  But the code logic that is accessing a window handle across thread boundaries, without regard to the owning thread destroying the window at any time, needs to be fixed.  That is certainly not an Indy/IntraWeb issue.

Edited March 21, 2022 by Remy Lebeau

[FPiette 383]

4 hours ago, Remy Lebeau said:

But the code logic that is accessing a window handle across thread boundaries, without regard to the owning thread destroying the window at any time, needs to be fixed.

TWSocket has ThreadDetach and ThreadAttach methods to switch from one thread (The one which created the component or the last attached thread) to another.  This simply destroy the window handle (ThreadDetach) and recreate it (ThreadAttach). There should be some hook or event in IntraWeb to plug the calls to those methods.