Redirect problem on Websphere

[roel croonenberghs]

We have an application (JSF 1.2) that checks if a user is logged in or not. If not, a redirect is done to the login page. This works fine on Tomcat. But when deployed on Websphere 7 it fails.
Firts request to a page an empty blank screen is returned. Second time (reload) the redirect works as it should be.

I have this as log when it fails;

User is not logged in and page is not public => redirecting to login
16:54:21,200 TRACE be.sofico.web.frmwrk.application.LoginController:94 - END afterPhase()
16:54:21,202  INFO org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager:198 - No context init parameter 'org.apache.myfaces.redirectTracker.POLICY' found, using default value org.apache.myfaces.custom.redirectTracker.policy.NoopRedirectTrackPolicy
16:54:21,208  INFO org.apache.myfaces.custom.redirectTracker.RedirectTrackerManager:209 - No context init parameter 'org.apache.myfaces.redirectTracker.MAX_REDIRECTS' found, using default value 20
16:54:21,210 DEBUG org.ajax4jsf.event.AjaxPhaseListener:69 - Process after phase RESTORE_VIEW 1

the code that does the redirect is this

if ("logout".equals(result)) {
				// User isn't logged in anymore, we just redirected back to login
				// page
				NavigationHandler nh = fc.getApplication().getNavigationHandler();
				nh.handleNavigation(fc, null, "logout");

and in the faces.config i have a navigation rule

<navigation-case>
	<from-outcome>logout</from-outcome>
	<to-view-id>/user/login.xhtml</to-view-id>
  </navigation-case>

Any ideas?

[Tim Holloway]

Welcome to the JavaRanch, Roel.

Actually, my first recommendation is one you'll swiftly get sick of hearing if you hang around here much, and that's to use the built-in J2EE security system instead of a Do-it-Yourself login/security framework. I've actually got a pretty long list of why DIY security is a Bad Idea, no matter how many Java books illustrate how to do things using a custom login, but the most important one of them all is that in over a decade of J2EE, working with apps of all stripes, including financial organizations and even military stuff, I've never yet encountered a truly secure webapp that's used a DIY security system. And, in fact, most of them could be subverted in under 5 minutes by people with only minimal hacking skills.

Although use of the J2EE container-managed security system is something I recommend in any event, WAS takes an especial interest in it, and that's possibly part of your problem. WAS is typically used in large Enterprise environments where there's a lot going on, security breaches can have serious financial/legal/national security implications, and management would really prefer a central security administration to having to ride herd over possibly dozens of one-off systems.

So while I regret that I can't offer an immediate solution to your problem, I can recommend considering use of a platform that's designed to be less of a problem to begin with.

[roel croonenberghs]

>Actually, my first recommendation is one you'll swiftly get sick of hearing

Then, don't you have a second recommendation?
I don't think the security is the problem here.
Anyway, it works perfectly well on tomcat and sun java webserver.

any ideas?

[Tim Holloway]

People don't think security is the problem. Right up until Vesuvius erupts.

Unlike regular application code, security failures are often undetectable. In fact, the best security exploits are unseen. That way, the Bad Guys can loiter around bleeding critical data from your organization virtually indefinitely, and occasionally injecting things to their own benefit. They can also tunnel through security holes in order to gain inside access to other, more critical resources in other applications and on other machines. Only kiddiez exploit security failures for instant pyrotechnics and blatant vandalism. One of the reasons why Java programming carries a higher price tag than "Git 'R Dun!" platforms is that security needs were part of the basic design both of the language and its standard platforms.

I repeat. When I first started working with J2EE, JSPs hadn't been invented yet. All we had were Servlets, get offa my lawn and in the snow. I've seen a LOT of webapps done by a lot of people, in a lot of organizations, and some of them in very critical roles. And NOT ONE of the ones with DIY security systems could stand up to even the wide-eyed innocent tricks that I myself know how to pull. I've got friends, however, who are downright Evil. One of them cracked a login system I'd been required to implement (in my pre-Java days) by taking advantage of a window of vulnerability that was only milliseconds in width.

Unless you are professionally trained in security and security is your full-time job, your system is insecure. And even then, cracks have been known to happen. For the rest of us, cleverness just won't cut it. We don't have the time or budget to do security up right even if we have the skills and know-how. After all, security isn't "productive". Far smarter to exploit the documented, debugged, tested, and field-proven work of people who are full-time security professionals than to fritter away effort on something that isn't going to hack it anyway (no pun intended).

So, no, I'm afraid you'll have to ask someone else if this is the course you intend to pursue. I just nag people.

[Tim Holloway]

Snarky after-comment. If you are at all tempted to believe that you can do Secure DIY all by yourself while simultaneously handling all the other needs of a webapp, I strongly recommend that you chase down the recent post-mortem analysis published on the web about the HPGary debacle where the hacker group Anonymous took them to the cleaners in revenge for being involved in the WikiLeaks incident. HPGary did claim to be full-time professional security experts (I suspect people are a little doubtful of that now). They got eaten partly by social engineering of the type that can be done in any organization that's run by the usual gang of idiots rather than say, an elite alien invasion strategic task force. But they also got their heads handed to them courtesy of several technical failures. One of which was a hole offered by a custom-written system with DIY security in it.

Security is a "weakest-link" issue. And in the HPGary case, the hole in the DIY security was how they broke in and eventually took over pretty much the entire operation.

[roel croonenberghs]

thank you for these useless replies.

[roel croonenberghs]

Anybody having an idea? why is it not working the first time, but after a second call to the same page, the redirect works correctly.