graff has asked for the wisdom of the Perl Monks concerning the following question:

Our web site is java-based :(, with jboss and tomcat :/, and one of the things this setup provides is a user authentication system, using the HttpSession javax servlet package (or class, or whatever it is), which maintains a persistent data structure on the server as the user navigates around our intranet.

A typical pattern of user behavior here is that you go to a url (a .jsp page) which is protected by the user-authentication setup, and that jsp page checks for your HttpSession to see if you're logged in; if not, you are redirected to a login page, and on successful login you get redirected back to the original url you wanted.

I want to write perl/CGI apps that can use the existing authentication, and I'm wondering if there is some way (via module or ad-hoc coding) to access the HttpSession data.

Presumably, I could impose on our java guru/maintainer to supply some other method or resource via java/jsp, to write a cookie for the user as part of the login process; then my CGI script could just look for that cookie (and redirect to the standard login page if it's not there, and hopefully get redirected back once the user logs in).

But when I asked the java guru, who knows as much about perl/CGI as I know about java (i.e. not enough), the first thing he suggested was: "well, just get your cgi script to read the HttpSession data..." (esp. things called "attributes" in that object). Well, I think that would be a great way to proceed, if in fact there is a way to do that.

Does anybody know if there is a way to do that?

Replies are listed 'Best First'.
Re: CGI for (or against) HttpSession?
by Joost (Canon) on Mar 30, 2005 at 23:46 UTC
    Usually, with tomcat, the session data is stored in memory in the JVM, so it could be hard to get at directly from perl :-) Especially since the data (values) in the session can be any java object (not just strings or primitive types).

    There are ways of configuring tomcat to store the session data externally, and you might then be able to get at it easier. Look at the tomcat documentation.

    If you don't need much information from the session, writing a webservice type interface to a simple java servlet/jsp page might be easier, though.

    "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
      the session data is stored in memory in the JVM, so it could be hard to get at directly from perl

      Just as I would have guessed. Thanks for confirming that. The notion of saving session data externally (e.g. in a temp file on the server?) seems a bit klunky, but it's worth looking into.

      If you don't need much information from the session, writing a webservice type interface to a simple java servlet/jsp page might be easier, though.

      Forgive me, but I don't know what you're talking about here. It's true that I only need a few short little strings (user-id, organization, permission-level -- less than 48 bytes altogether), and I don't have any trouble with the jsp stuff per se (our java guy provides a jsp template for static page content); so, what would a "webservice type interface to a simple ... jsp page" consist of? Is it some simple, generic thing in java/jsp, or some simple, generic thing in CGI? (Does this become a non-perl question?)

[reply]
[reply]
[d/l]
Re: CGI for (or against) HttpSession?
by crashtest (Curate) on Mar 31, 2005 at 02:02 UTC
    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.
[reply]
[d/l]
[select]
      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?)

[reply]
Re: CGI for (or against) HttpSession?
by PodMaster (Abbot) on Mar 31, 2005 at 05:56 UTC
    If you use the webserver to authenticate users (http authentication) you don't have to worry about fishing out data from the JVM.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

Back to Seekers of Perl Wisdom