JSP and htaccess

I’ve always hated Apache. I discovered Roxen (nee Spinner)  long before Apache and it has always struck me that Apache projects willfully obfuscate and convolute themselves and their documentation in a Microsoft-esque attempt to build jobs for admins.

I was trying to be lazy and set up some htaccess based auth (hacked mod_auth_mysql into a reasonable little PN:auth module). It’s all fine except for the fact that I can’t figure out (google, ask and lycos are no help) how to get at the authenticated username from within jsp… Is it even passed from apache to tomcat?

Yeah, I looked at tomcat’s container based security, but I wanted security that both apache/tomcat shared. If/when I ever have to set up some degree of limited access to wiretap, I’ll have to take a long weekend and brush up on my Apache obscurities. Bleah.

11 Comments

I don’t know Java / JSP or Tomcat, but I would imagine that the Apache module would be completely transparent to Tomcat, and wouldn’t strip anything out. Thus the username would still be in the HTTP request and accessible by the normal means for getting that information. Something like this, I think:

http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/HttpServletRequest.html#getRemoteUser()

WordPress stripped the trailing () off the target of that URL.

Hrm. Not sure how to access that via ${…} ${request.getRemoteUser()}, maybe?

I hate HTTP Auth with a passion that burns. It’s so terrible in any and all forms. Where shall I start?

1) Cannot auto-login a user in IE (MS claims security)
2) Cannot style login prompt
3) Plain text
4) Password hash algorithm differs based on OS
5) I dare you, DARE I SAY, to implement a logout feature that doesn’t close the browser

In every implementation of a website where I’ve thought HTTP Auth would be a good idea, I’ve ALWAYS had to rewrite it with a cookie based session.

Yes, Oliver, that should work.

And as much as I agree that apache projects deserve a little hatred (especially the Java ones), this really isn’t their fault.

As for patton:
re 1) since it does let you store the account info I think it’s only about being able to choose the user at all. If it would auto-login, how could you choose a different user? Though IIRC client certificates will be selected automatically, if there is only one for the given realm.

re 3) only for Basic auth over a non-ssl connection. If security matters in the slightest, you’d be using SSL anyway.

re 4) I never really bothered with Digest, to be honest, but shouldn’t that be plain MD5 and merely depend on a reasonably recent browser? Not that MD5 is all that secure anymore anyway.

re 5) Sending another 401 reply should work, I would think. It’s a bit ugly in that you’d just get a login dialog again, I guess but it should stop the browser from resending the same Authorization header on following requests.

Not saying anything against form-based/cookied auth but it has its own set of similar issues. If establishing trust in the client is necessary, I’d rather go for client certs.

${request.getResponse()} gives an error about specifying a namespace when no default is given – which makes me think its not trying to call request -> getResponse().

Re: Roxen. It has just always done a lot of things the way Apache had to learn to. It had a web-based management/configuration from the very start. The module system, based on uLPC (the MUD language), naturally lends itself to this interface, and I notice that Apache’s module system came to be rather a lot like Roxen’s, as did Sun’s servlet module system.

And from day 1, Roxen had an XML-based extensible scripting system – very similar to JSTL in so many ways, just 5-6 years ahead of it ;)

Hey Kury:

re 1) since it does let you store the account info I think it’s only about being able to choose the user at all. If it would auto-login, how could you choose a different user? Though IIRC client certificates will be selected automatically, if there is only one for the given realm.

Auto-login in the sense of:
http:username:password@example.com

I cannot think of any way of having IE auto-pass HTTP Auth credentials, because they don’t allow the above example due to security reasons.

re 3) only for Basic auth over a non-ssl connection. If security matters in the slightest, you’d be using SSL anyway.

Yeah this is true, except that I never did like the fact that the user credentials are continually passed for each page request, verses a session token.

re 4) I never really bothered with Digest, to be honest, but shouldn’t that be plain MD5 and merely depend on a reasonably recent browser? Not that MD5 is all that secure anymore anyway.

Nope, Apache on Windows uses some crazy algorithm that I cannot remember the name of. Really annoying.

Example output (notice the MD5 line which isn’t true at all)

C:\Program Files\Apache Software Foundation\Apache2.2\bin>htpasswd -b -n usernam
e testpassword
Automatically using MD5 format.
username:$apr1$mb4…..$vdnzfPbbFGTKxCM0aZSws0

re 5) Sending another 401 reply should work, I would think. It’s a bit ugly in that you’d just get a login dialog again, I guess but it should stop the browser from resending the same Authorization header on following requests.

I tried working with this once and it just didn’t play out. The ultimate problem was the cancel button. Sending a 401, will cause the browser to display the login again, however in IE, hiting cancel will cause the previous page to be displayed (but doesn’t reload it). It will also keep the previous HTTP Auth credentials. Basically creating an un-logout button.

I tried doing all kinds of magical tricks within the code to work around this issue but it just wasn’t working out. Btw, all this was with Apache mod_auth .

That block should look like:

C:\Program Files\Apache Software Foundation\Apache2.2\bin>htpasswd -b -n username testpassword
Automatically using MD5 format.
username:$apr1$mb4…..$vdnzfPbbFGTKxCM0aZSws0

Cheers. That’s good to know. I live a relatively sheltered life having to rarely deal with IE. :)

request.getUserPrincipal.getName() should give you the username of the authenticated subject in a servlet/ jsp environment.

the question is now, if the authentication on your apache webserver is transmitted to your tomcat installation.

i’m not en expert in the administration area, so i’d recommend to look at the mod_jk documentation (at least i’s expect it there). if there is no easy way, you might want to try kerberos as a single-sign-on solution.

http://en.wikipedia.org/wiki/Kerberos_%28protocol%29

cheers,

misled

.htaccess is very confusing and when java provide url rewriting then why we use .htacess and by this you can easily convert your url seo friendly.

paste below code in **WEB-INF/web.xml**

UrlRewriteFilter
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter

UrlRewriteFilter
/*
REQUEST
FORWARD

And you need to import their jar file.
Step is given on this blog where i found this tutorial
http://geekonjava.blogspot.com/2014/06/how-to-make-seo-friendly-url-in-jsp.html

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: