Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

REMOTE_USER env variable not passed from apache to tomcat?

 
Shane Doucette
Greenhorn
Posts: 4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I'm having troubles with reading the REMOTE_USER variable in a servlet.
Here's some environment background: we have a set of jsp applications, served by tomcat 4.0.4 thru apache via mod_jk, which are protected by .htaccess. We have to use .htaccess files, as we are having the users authenticate using a Kerberos ID and password.
The following code used to return the username entered at the .htaccess prompt, when we were using Tomcat 3.2.2, but when we moved to 4.0.4, getRemoteUser returns null.

Now, I've read that I may need to create a realm in my server.xml, but that doesn't seem to be the way to go for my needs, as it's required that I use the .htaccess. Unless of course there's some sort of kerberos realm I can define...
Anyhow, if anyone has any suggestions as to what we might be doing wrong, it would certainly help. We've been banging our heads against this for two days now!
Thanks,
shane.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 17620
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmmm. Sounds like a possible conflict between Apache user validation and J2EE user validation.
While it's possible that this is just a bug in the Apache-to-Tomcat pipeline, I think that in an "ideal" world, a J2EE app isn't supposed to be be dependent on outside help - their security system is expected to be self-contained. Otherwise portability suffers and it's even possible that the Apache server and Tomcat servers might conflict about what's allowed and what isn't. So most likely, to truly fix things, you're going to have to use the javax.security packages with a Kerberos security plugin rather than depend on Apache. The self-containedness aspect means that to make a truly portable WAR/EAR, you must also be serving up the HTML and multimedia files from Tomcat, BTW.
Why the change? Tomcat 4 implements a newer J2EE standard. Formerly, thanks to U.S. government restrictions on "munitions", encrpytion wasn't part of the Java standard package set.
Note that if "purity" would kill performance or require a major rewrite, the source code to Apache and the connector are available for the tweaking.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic