File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes FORM based authentication problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "FORM based authentication problem" Watch "FORM based authentication problem" New topic
Author

FORM based authentication problem

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16308
    
  22

OK, it's my turn! I've been working with FORM-based authentication since about 2000 on Windows, Linux, Solaris and maybe even the odd IBM iSeries. No problems. Until now.

I have one (and only one) server at a particular hosting provider that is positively off the wall. When I access a secured resource, it doesn't present the login form. Instead it pops up a Dialog, meaning it's attempting BASIC instead of FORM. It does authenticate - only valid user IDs and passwords are accepted. However, it doesn't honor security roles!

We upgraded the OS, I installed a fresh copy of Tomcat and the latest Sun, er, Oracle JVM. No change. I switched the proxy off Apache, set up a firewall redirect from port 443 to 8443 to compensate, verified that 443 wasn't being listened to and 8443 belonged to Tomcat. Checked the 8443 Connector parameters. All good.

This is an app that works just fine on my desktop and development server, although I don't route through Apache on those systems. I've got other systems at the same hosting service that don't have a problem with form-based authentication. I'll admit that since there are other fingers in this particular pie, there may be things going on I don't know about, but if there ARE, I need to know them, and I haven't a clue.

Anybody ever seen anything like this before?

Customer surveys are for companies who didn't pay proper attention to begin with.
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14688
    
  16

web.xml is correctly deployed, isn't it ? It contains the form authentication settings ?


[My Blog]
All roads lead to JavaRanch
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16308
    
  22

Nothing so simple, alas. My desk, test and production WARs are the exact same file. Only production misbehaves.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 10290
    
168

Tim Holloway wrote:
We upgraded the OS, I installed a fresh copy of Tomcat and the latest Sun, er, Oracle JVM. No change. I switched the proxy off Apache, set up a firewall redirect from port 443 to 8443 to compensate, verified that 443 wasn't being listened to and 8443 belonged to Tomcat. Checked the 8443 Connector parameters. All good.
....
I'll admit that since there are other fingers in this particular pie, there may be things going on I don't know about, but if there ARE, I need to know them, and I haven't a clue.




Maybe enabling the AccessLogValve on that Tomcat instance might give a hint probably. At the very least it will prove that the request is infact being handled by that instance.


[My Blog] [JavaRanch Journal]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16308
    
  22

Doesn't seem to be much doubt that what security applies is being handled by Java, since there's no other place where the necessary config to validate userid/passwords in the database occurs. But the Valve idea is a good one. I have been wondering if the actual Realm processing isn't being completely bypassed and the login is somehow being presented by old DIY security code that wasn't destroyed back when I first overhauled this puppy. Tracing URL requests may prove instructive.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16308
    
  22

I found it:


This was SUPPOSED to enhance performance in JSF. Without it, roughly a Megabyte of JavaScript code is repeatedly downloaded per page because Tomcat ruthlessly suppresses cacheing directives when SSL is in use (there's a reason for it, but not one that applies here).

What is ALSO decided to do on this particular server was silently force the BASIC authenticator to be used instead of the FORM authenticator. So I've turned it off for the moment and now I have to see if there's a related option for form-based authenticators.

What makes this really bizarre is that the cache suppression suppression is a characteristic I don't want on login (authentication), but on post-login pages where I'm already authenticated. But that little nuance doesn't seem to be accounted for.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: FORM based authentication problem