in reply to Browsers as stand-alone UI

Just embed a "web" service into your Perl application. Have it open on a custom port. Run the browser to point at that custom port. http://localhost:3456/ This is how many applications offer web-browser front ends, including Slim Device's SLIMP3 server (in Perl!), the CUPS printer configuration service, and several others.

--
[ e d @ h a l l e y . c c ]

Replies are listed 'Best First'.
Re: Re: Browsers as stand-alone UI
by dragonchild (Archbishop) on Apr 07, 2004 at 18:14 UTC
    This may be an unreasonable design goal, but I wanted to have the end result meet the following requirements:
    1. The setup work required to install this application would ideally be "Copy stuff to this location and make a link on the Desktop"
    2. Launching this application would be nothing more than clicking on the link which would bring up IE.
    3. No (additional) security holes would be created by this app.
    4. Preferably, no security holes would be used benignly by this app.

    I suppose that #2 could be handle by a WinSript that would launch the server, then launch a webbrowser with the appropriate link ...

    ------
    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

[reply]
      Nothing wrong with your requirements, and nothing that is incompatible with "run your own web service."
      1. Copy perl scripts and data files to this location, and make a link on the desktop that launches the main perl script. The main script can adjust @INC to use its own private stash of modules.
      2. A perl script can bring up the user's IE with a simple statement: system("start/b  http://localhost:2345/").
      3. If your web service only accepts connections originating from localhost, it's not going to open up problems on the LAN or internet.
      4. I haven't suggested you exploit any vulnerability to implement this.

      It would be harder to decide when to stop, since the user's free to wander off and browse other pages, or close the IE session.

      Update: Look into HTTP::Daemon for a start, but that's only one option. I'm sure there's others.

      --
      [ e d @ h a l l e y . c c ]

[reply]
[d/l]
[select]
        Bear in mind though that any machine that allows ssh connections will also allows users to connect to any port as if they were on the local machine and tunnel it to their remote machine. They will need an ssh login though.

        Probably not a problem but it might still be worth having a username and password prompt on the web interface 'just in case'.

[reply]
Re: Re: Browsers as stand-alone UI
by Rhandom (Curate) on Apr 07, 2004 at 21:59 UTC
    This is exactly what I did for a membership survey/directory program for a local church congregation. The computer was a Windows XP box with no network connection or anything. But I made a module with its own basic server. Then I ran requests from localhost. At the time I used Active State to do things. Now- I'd skip that step and just use a PAR executable. Copy one file. Click on it and your off. If you can get fork to work on XP you could fork and exec an IE window. Nice and easy.
    my @a=qw(random brilliant braindead); print $a[rand(@a)];
[reply]

In Section Meditations