in reply to CGI for (or against) HttpSession?

I am a little confused about your set-up. You say your web server is Tomcat, but you are also running Perl CGI scripts. Where are these scripts running? On a separate web server, like Apache, or on the same Tomcat server?

If your scripts are running on a separate server, there is no way to access the HttpSession objects. They live in the Tomcat server process, and would need to be exposed somehow for you to get to them. Exposing the session attributes through Cookies (as in your initial idea) is probably the easiest way, but also the most expensive. The data would be passed on each HTTP request.

Keep in mind, too, that Cookies are per-domain. If your perl script is running on a server that isn't in the same domain (or sub-domain, I think), you won't see the cookie.

When [id://Joost] talkes about a webservice type page, I believe he is suggesting having a simple JSP/Servlet running on Tomcat. Your Perl script would issue a GET request to the servlet (maybe using LWP), and the servlet would respond with the information you need, in an easily parseable format. For instance, if you had the Tomcat session id for the user, you might call GET http://your-tomcat-server/app/session_info?id=1234567, and the servlet might respond with a body of name=Joe Blow; org=IT;.

I have never heard of running Perl scripts on Tomcat, but I suppose it would be possible to create a simple wrapper Servlet that then executes the Perl script. If that is the case, and you rolled this wrapper yourself, the wrapper could provide the pertinent data from the HttpSession object as command-line arguments/environment variables.

Replies are listed 'Best First'.
Re^2: CGI for (or against) HttpSession?
by graff (Chancellor) on Mar 31, 2005 at 03:06 UTC
    I am a little confused about your set-up.

    Some people in our shop feel the same way ;) -- the setting is a medium-size "research branch" at a major university, where we have our own, single dedicated web server for public and limited-access web services (update: what I mean is: there's a single machine that runs a couple different virtual servers -- one http, one https -- from a single httpd.conf). There's a core "business operations" component on the server that handles stuff like invoicing, employee time sheets, etc, which is solid java/tomcat, and access-control is a basic part of this.

    But apart from the core operations, we have several programmers (including me), who are engaged in various research projects and need to be able to put up forms and/or dynamic pages (again, both public and limited-access) with a minimum of development time and a maximum of flexibility and safety -- hence we work with perl instead of java, and the site ends up being a rather unpredictable mix of web-programming approaches.

    (I'd love for the core operations to be (mod_)perl/cgi, but that's outside my scope...)

    Anyway, us research-project programmers have this ongoing issue when it comes to creating limited-access web services: do we create yet another database of userids/passwords, or do we kluge some weird amalgam of java/jsp + perl/cgi in order to use the existing access control? For the cases where the same set of users want to access both core stuff and research project stuff, the amalgam approach has advantages -- we just need to figure out a sane way to do that, which doesn't require more java coding for each new project or cgi service.

    So, the "per-domain" feature of cookies is not a problem, since we're talking about java+cgi stuff on the same server.

    Your explanation of Joost's idea seems to make sense -- thank you. I'll discuss that with the java guy here, though I still have a few conceptual gaps about it; like, I'm not sure how a perl/cgi script gets to know a session-id from tomcat for a given user.

    To clarify, my task is: user ABC wants to access cgi resource XYZ, which happens to require login authentication; since ABC already has a user account on tomcat, I want XYZ to be able to tell whether a client has logged in via tomcat, and if so, who this client is (i.e., is it ABC, or someone else?)