• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

FORM based authentication problem

 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Sheriff
Posts: 14691
16
Eclipse IDE VI Editor Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
web.xml is correctly deployed, isn't it ? It contains the form authentication settings ?
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nothing so simple, alas. My desk, test and production WARs are the exact same file. Only production misbehaves.
 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic