Gif-viewer with small code using CGI/HTML

[MU]

In another thread, Sunburnt talked about, that it would be nice to program in a HTML-like syntax.

Well, at least you can use HTML to build the User-Interface of your program/script, using CGI (Common Gateway Interface).

It is a technique, not a programming-language.
So I will show how to use it with Puppybasic.
You could use a pure shellscript, too.

CGI needs a Webserver - Puppy has Ghttpd.
You should not start it with the defaultvalues, as it is a high security-risk: Ghttpd can access your whole root-filesystem!

Edit /root/ghttpd/httpd.cfg
Replace
SERVER_HOSTNAME = "any"
with
SERVER_HOSTNAME = "localhost"

Now install:
http://dotpups.de/files/PuppyBasic-CGI-Demo.pup (8 kb)

Now run the Webserver in a consolewindow:
/root/ghttpd/httpd

In Dillo, enter this URL (with the port you chose):
http://localhost/cgi-bin/gif-view.cgi

You should see:


You can click the links, to browse the folders:


If you click on a gif, it is displayed in a new window.

The program consists of 4 Parts:
/usr/lib/wxbasicscript/basefunctions2.inc (updated library for Puppybasic)

/root/ghttpd/cgi-bin/gif-view.cgi
This is a shell-script, that generates the HTML-header, and starts the Puppybasic-Program.

/root/ghttpd/cgi-bin/PB-gifview/mu1.pb
This is the main-"program":

Code: Select all

#!/usr/bin/puppybasic
option explicit
DIM STARTDIR

include "/usr/lib/wxbasicscript/basefunctions2.inc"
include "/root/ghttpd/cgi-bin/PB-gifview/mu1functions.inc"



Dim folder = readparameters()

print "<table border=1 bgcolor='#BBBBFF' width=100%>"

print "<tr><td colspan=2 align=center><h3>CGI Gif-Viewer</h3></td></tr>"
print "<tr><td width=50%><b>Folders:</b></td><td width=50%><b>Files:</b></td></tr>"

print "<tr><td valign=top width=50%>"

lsdirs(folder)

print "</td><td valign=top width=50%>"

lsfiles(folder)

print "</td></tr></table>"

Short, isn't it?

/root/ghttpd/cgi-bin/PB-gifview/mu1functions.inc
Some helpfull stuff.

This reads directories, and generates the links.
Note, that links will get a number in the end, made of Date() and Time().
This makes shure, the Webbrowser will reload the script, and does not load it from cache.

Tip:
To see errors you make when altering the example, open a Consolewindow to monitor the Puppybasic-errors using this command:
tail -f /root/ghttpd/wx.err

Mark

[jmarsden]

There's a big difference between what a program outputs (HTML in this case) and what it is is programmed in (some sort of BASIC dialect in this case). If I write a shell script that outputs HTML, it is still a shell script, not an "HTML program". What you are proposing is a way to write BASIC programs that output HTML and so have a browser-based interface, not a way to code programs in HTML or an HTML-like syntax at all.

Anyway, my real reason for replying was something totally different! You wrote:

CGI needs a Webserver - Puppy has Ghttpd.
You should not start it with the defaultvalues, as it is a high security-risk: Ghttpd can access your whole root-filesystem!

Edit /root/ghttpd/httpd.cfg
Replace SERVER_PORT = "80" with SERVER_PORT = "5123"
Use another port that is blocked by your firewall!

I don't understand the logic behind this recommendation. Changing port number has a very small effect on security. A quick portscan will find an open port 5123 as easily as port 80.

If you don't want the httpd you are running to be accessible from outside the machine it is running on, the usual way to make that happen is simply to make it bind only to localhost -- no need for a firewall, just don't listen on the network interface! This is true for all network daemons, not just web serviers, of course.

Going one step further, if you want to restrict your httpd to accessing only files under a non-root user's directory and readable by that user, make it run as, say spot.

Example: as root, move the thing to somewhere owned by spot, and configure and run it, by doing something like

Code: Select all

mv ~/ghttpd ~/spot
cd ~spot/ghttpd
sed -e s/%root%root/spot%g -e s%any%localhost% -e s%80%5123% httpd.cfg >httpd.cfg.spot
mv httpd.cfg.spot httpd.cfg
chown -R spot:spot ~spot/ghttpd
su -c "~spot/ghttpd/httpd" spot &

and you should get a local web server running as a non-root user and only bound to the lo (locahost) interface, not to your Internet connection. You can check where it is listening by the usual

Code: Select all

netstat -ntlp | grep 5123

You can check who it is running as with

Code: Select all

ps -axwwu | grep httpd

Now that is reasonably secure, at least by Puppy standards

Actually, just changing "any" to "localhost" should be sufficient for normal hobbyist use, the rest is perhaps slight overkill IMO, localhost should be the default setting for ghttpd's hostname, not "any"! Should we tweak that in 1.0.9?

Bottom line: if you can only make one small change to httpd.cfg for the sake of security, don't change the port, change the host from any to localhost. If you don't like it running as root, then a few more changes can handle that too.

Even with these changes, you still can't really program in HTML or something that looks like HTML, because HTML is a markup language and not a programming language.

Jonathan

[MU]

Of course you can't program with HTML.
HTML is a markup-language, not a programming-language.

But you can use it to generate the User-Interface, this is what I wanted to describe.
So it is an alternative for people who can't get familiar with Gtk or Tk.

---
I don't want to run as spot, as the idea in this case is to get full access to the machine, just as if you ran a "real" program (Perl/Gtk, Tcl/Tk or whatever).
But thatrequires, the program can only be run from the local user, not from remote.
If you set the host to localhost, really noone else can start it?
I was not shure about that.
Mark

[MU]

I made a Dotpup with "Dillowidget".
That's simply the Webbrowser Dillo as a "Popup-Window" without Menubar and other irritating stuff

An examplescript is included, it creates a small widget on the top of the screen:

Code: Select all

#!/bin/bash

xmessage -center -buttons "start Widget","stop Widget" choose
r=$?
if [ "$r" == "101" ];then
  dillowidget -g 300x100+100+00 -f file:///usr/local/Dillowidget/test.htm &
  exec $0
fi

if [ "$r" == "102" ];then

  ps |grep "dillowidget -g 300x100+100+00"|grep -v grep|sed "s/ .*//"|while read a;do kill $a;done

fi

To test the CGI from above, don't start test.htm, but use this line:

Code: Select all

dillowidget -g 300x100+100+00 -f  http://localhost/cgi-bin/gif-view.cgi &

In combination with CGI-scripts you can create a small borderless Monitor, that floats over all other Windows.
You would realize the "user-interface" with some Pictures, that are simple HTML-links, that call another CGI-script, that executes your commands.
Unfortunately Dillo can't do Javascript, that would give interesting Options.

200 kb: http://dotpups.de/files/Dillowidget.pup

Mark

[jmarsden]

Of course you can't program with HTML. HTML is a markup-language, not a programming-language.

Maybe this is just a human language misunderstanding, then. Earlier you said

In another thread, Sunburnt talked about, that it would be nice to program in a HTML-like syntax. This is in fact possible...

Do you understand why this sounds like you were saying programming in something like HTML is possible? Thanks for clarifying.

If you set the host to localhost, really noone else can start it?
I was not shure about that.

Yes. Noone outside your machine can get to that daemon, if it only binds to localhost. TCP connections are defined by exactly four things: source IP, source port, destination IP,destination port. If the destination port is 127.0.0.1, which is unroutable, then noone can route packets to it over a network. Even if an attacker carefully hand-crafts a packet with a 127.0.0.1 destination IP address, and somehow gets it out onto the wire, it won't get routed to a remote machine's 127.0.0.1, neither the sending machine nor any intermediate routers can possibly know where to send it. So the only way in from outside the server machine would be to break into some other service on the machine that is network-accessible, and use that break in to gain local access to the 127.0.0.1 listener.

Jonathan

[MU]

Ok thanks, I updated the first message
Mark