Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Perl-Sensitive Sunglasses
 
PerlMonks  

Limiting access to a local web application

by akho (Hermit)
on Aug 03, 2008 at 21:39 UTC ( #701920=perlquestion: print w/ replies, xml ) Need Help??
akho has asked for the wisdom of the Perl Monks concerning the following question:

This is not strictly Perl related (possibly, not Perl-related at all), but maybe some wise monk can help me.

I have a small personal project — a Web application that should be run locally by the user. That probably makes it a desktop application, but the interface is through a browser (it kinda makes sense to represent this application as an interactive document). So I run a web server on a port with a large number.

The problem is that any user on the same computer accesses the same instance of the application, which is not good. I can ask the user for his login/password, of course, but I feel silly if I have to enter a password for a website that is actually on the same computer — it doesn't feel like a desktop application at all.

So: I need to have an application that is accessible through a web browser, but does not require authentication, while providing different content to different users. How can I do that? I currently use CGI::Application, but the Web part is not that big, so I'm willing to switch.

(one possible option would be to use fuse and the file:// protocol instead of http; but that's too much trouble)

Comment on Limiting access to a local web application
Re: Limiting access to a local web application
by shmem (Canon) on Aug 03, 2008 at 22:15 UTC

    It is not too clear to me what you mean, but - you can, in your web server config or script, differentiate between requests coming in through the loopback or external interfaces. If you need a username as parameter, you have no way without authentication, since http requests are by default anonymous. Only after requesting authentication (e.g. sending back a 401 status code and an Authentication line, the client will send a username embodied in the next GET or POST request.

    You could use Kerberos to handle that transparently.


    --shmem

    _($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                                  /\_¯/(q    /
    ----------------------------  \__(m.====·.(_("always off the crowd"))."·
    ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
      Well, all my requests come through the loopback interface, so I've already eliminated external requests.

      I know http requests are anonymous; but since both the server and the client live on the same system, I thought maybe I can somehow determine from which local user the request came. I understand there is not much hope, though.

Re: Limiting access to a local web application
by jethro (Monsignor) on Aug 03, 2008 at 23:01 UTC
    You can use cookies.

    If your cookie isn't set, this is a new user. If you need to know which user exactly then you can ask for a name (and put that name into the cookie). No need to ask for a password. If you just need to differentiate between users (without needing to know a name) then the value of the cookie is just a random number you store somewhere.

    If it is set you check the cookie and know now which "thread" is doing the asking.

      That won't prevent users from easily impersonating each other
        No, but he didn't say that he needed that. Not everything needs to be locked with key and authentication. Think intranet wiki, work group data, user preferences

        If authentication is important, there might be other ways: A login/startup script could put a personalized cookie (i.e. a random number) into the cookie file of the browser and tell the server which user has which cookie number. This is a hack since you have to know which browser is used and if that browser changes its cookie file syntax, your app will malfunction and could even stop the browser from running.

        But if the browser is not the normal browser but a separate instance started and solely used by the application this would be acceptable.

Re: Limiting access to a local web application
by AltBlue (Chaplain) on Aug 03, 2008 at 23:20 UTC

    You might be able to do that by plugging some firewall that knows how to deal with "packet owners", denying all connections to your local web server if the outgoing packet does not come from "The user".

    Here's a Linux example, assuming that user's ID is 1234 and the web server runs only on local interface (lo), on TCP port 80:

    # iptables -A OUTPUT -p tcp -m owner --dport 80 -o lo+ ! --uid-owner +1234 -j DROP
Re: Limiting access to a local web application
by blahblahblah (Priest) on Aug 03, 2008 at 23:42 UTC
    What OS, browser, and web server are you dealing with? (Or do you have to support more than one combo of those?)

    There might be some server-specific or browser-specific solution. For example, I think that for IIS if you disable anonymous access and enable integrated authentication, then IE will just send the user's credentials along, without ever prompting for a username/password. I think there's also a mod_auth_something for apache that can be configured to work the same way, checking Active Directory for its data.

    You might be able to find a simpler solution based on the fact that the server and client are the same machine. For example, if you are running all of this on a single-user desktop windows machine, your cgi app could (I think) find out the currently logged in user through WMI. You're probably better off going with a more standard method though. Writing a home-grown authentication method is just asking for trouble. Even if nobody cares to hack into your app, they might still exploit a bug or oversight in your scheme to gain access to other parts of the system. When your users whine about having to type in a simple id & password (just once if you use cookies), tell them it's for their own data security. They should get over it quickly.

Re: Limiting access to a local web application
by Anonymous Monk on Aug 04, 2008 at 07:00 UTC
    Does each user get his own copy of the server?
      Yes, why not.
        Make up a random number on first request and set a cookie. Then require that the number is valid on each subsequent request.

        Keep the random number per server or per session, depending on whether you want to have one user per server or many.

        /J

        Then how are you having a problem? Let each server pick a different port, because they can't share the same one.
Re: Limiting access to a local web application
by dHarry (Monsignor) on Aug 04, 2008 at 07:01 UTC

    To me this seems like a good example of when not to use a Web based solution.

    I have a small personal project — a Web application that should be run locally by the user. That probably makes it a desktop application,

    It probably does yes.

    but the interface is through a browser (it kinda makes sense to represent this application as an interactive document). So I run a web server on a port with a large number.

    If it makes sense to represent the user interface as an interactive document it does not necessarily mean: web based solution. As far as I know most GUI’s around have widgets for representing documents as well. Take for example products like oXygen and XMLSpy: Fat clients in which the interface can be presented as an interactive document. I am sure there are many more examples.

    My advice would be to rethink your solution. It would save you a lot trouble.

      Well, yeah, they got widgets. I'll just need to add tab browsing, history, bookmarks and a dozen other things — and I'll be fine.
Re: Limiting access to a local web application
by Anonymous Monk on Aug 04, 2008 at 07:34 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://701920]
Approved by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2014-04-20 07:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls