#581 no way to stop httpserver.lgo

[DanielAjoy]

While playing with httpserver.lgo I got to the point where I put

fd in the Command textbox (in the browser)
100 in the Input textbox

and I got

The request body was malformed.

So I went to the source code and added a print statement.

Then I thought I need to restart the server, but found no obvious way to even stop it.

I typed

throw "toplevel

in the Command window, but when I pressed the "Forward 10" button then command was still received and executed.

I was expecting the server to stop receiving commands.

[David Costanzo]

Hmm. I'm surprised that it broke so quickly. The FMSLogo network API precludes graceful handling of concurrent requests. It also requires a new connection per request (contrary to what most browsers expect). When I tested it with an older Firefox and Chrome, they were compatible with httpserver.lgo when used from a single window, but maybe newer browsers aren't. Which one did you use?

You can stop the server shutting down the networking subsystem NETSHUTDOWN.

If you want to "bounce" the server (stop and restart it), you can run HttpServer.Start. This shuts down the network subsystem, then restarts the HTTP Server. I could add an HttpServer.Restart that just calls HttpServer.Start if you think that would make it more discoverable.

[DanielAjoy]

I'm using Firefox 96 and Windows.

I got the "The request body was malformed." because I typed "FD" instead of "FORWARD"

I hadn't read the code that checked that the command should be exactly one of a limited list. I thought the COMMAND prompt in the browser was an invitation to try arbitrary Logo commands.

The error 'The request body was malformed.' threw me off because FD 100 is a valid Logo command, It is just not one supported by the server.

Any way, I thought

throw "toplevel

stopped everything.

Is it true then that there is no ONE step to stop every background process running? What other background processes can be started in FMSLogo that could be invisibly running in the background without the user knowing?

I think it would be good to have visual "led lights" in the commander window showing that they are still running...

Other Logos have the STOPALL command and I had implemented it in my library as

throw "toplevel

[David Costanzo]

Daniel Ajoy wrote:

I hadn't read the code that checked that the command should be exactly one of a limited list. I thought the COMMAND prompt in the browser was an invitation to try arbitrary Logo commands.

It supports a limited number of procedures because FMSLogo has some procedures that would turn httpserver.lgo into an easily-exploitable vehicle for remote execution of arbitrary code (notably SHELL and DLLCALL). Since this is sample code that others might extend, I wanted it to be secure-by-default. I think network security must be taught at the same time networking is taught...for the same reason you have to pass a safety course before driving a car.

That said, "FD" could be allowed as a synonym for FORWARD. There could also be a different error message when the command is unsupported and when the instruction is malformed. I chose not to do this because this is information disclosure that goes against good security practices, as it informs an attacker when the server has taken a different (possibly exploitable) code path.

I added the free-form command execution to the web page not to show remote execution but to show (and test) that remote execution of arbitrary commands doesn't work. Maybe the web page should include that information.

If you have suggestions or a patch, please attach it to this ticket.

Daniel Ajoy wrote:

Is it true then that there is no ONE step to stop every background process running? What other background processes can be started in FMSLogo that could be invisibly running in the background without the user knowing?

Technically, THROW "toplevel does what you expect. In this case, there was no code running in the background. There are, however, callback instruction lists that are registered to handle events. Commands which come to mind to unregister these callbacks: MOUSEOFF, KEYBOARDOFF, NETSHUTDOWN, CLEARTIMER. There are other commands which cause environmental side-effects that are neither running code nor registered callbacks, like MIDIOPEN, BITCUT, PENUP, DEFINE, etc. I don't know if you want to reset that state as well.

George had made CLEARSCREEN a little like a STOPALL, which I find very annoying because it erases all of my BITMAPTURTLEs and I have to recreate them.

Daniel Ajoy wrote:

I think it would be good to have visual "led lights" in the commander window showing that they are still running...

There is an LED light: the "Halt" button is enabled while code is running and disabled when no code is running.