This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Five Lines of Code and have Christian Clausen on-line!
See this thread for details.
Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Login (protect my site)

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

i have a JSF aplication and use (primefaces, mysql, maven and spring). I implement the login dialog for my application. I have the Problem, that when the user know any dialog name in the application, he can enter the dialog name in the url and use my application (so that it bypasses the login).

How can i force that when the user typ in the url a dialog name the application will forward the user to the login page .

Best regards,
Posts: 989
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Use JAAS for security in web applications which allows you to define security constraints for every url in your application.
Posts: 43016
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch.

It sounds like you have JSF URLs that are accessible directly - a widely used approach these days is to keep JSPs (and JSFs etc.) where they can not be accessed directly, for example in a directory inside of WEB-INF. That way, you can get at them only via controller.

As to securing them, servlet security is the way to go:
Saloon Keeper
Posts: 22248
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have worked with J2EE since before they invented JSPs. Done/seen all sorts of projects, including financial and even one or 2 military ones.

And virtually every one of them that implemented their own login/security system could be easily cracked, often by non-technical personnel, in under 10 minutes.

What Ulf calls "servlet security" is the J2EE standard container-managed security subsystem. It is an integral part of J2EE, supplied with every J2EE server, even the minimalist ones like Tomcat. It was designed, debugged, and tested by full-time security experts. As opposed to "we need this system in production by Friday, and by the way, don't forget to write some security code into it".

It also has the virtual of being a wrap-around system that prevents many types of attacks from even reaching the web application. What can't reach it can't exploit it. And it's declarative, which means less code to be written and debugged.

I realise that virtually every book ever written on J2EE has a "login screen" sample in it. All I can say is

Many apps only need coarse-grained security. A few basic roles that protect whole pages or functions. The container security system is sufficient for almost all of this kind of app.

Some apps support a finer-grained security system with subfunctions that can be switched on or off for a user. The container security system can serve as the first line of defense for a number of security products that supply this sort of thing as well.

In short, there are very, very few situations where I don't use container-managed ("servlet") security when I need a secure web application. And, incidentally, the container-managed system is URL-based, so the fault that you are experiencing is one that it very specifically addresses.

JSF does add one wrinkle to the standard configuration, however. As you've doubtless noticed, the URLs in the client (browser) navigation control don't always track with the page (View) being displayed. Since container security is based on the URL and not the page, it is necessary to ensure that that does not happen. You use the "redirect" JSF navigation option to do that when dispatching to protected Views.

I like tacos! And this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic