Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Login (protect my site)  RSS feed

 
Samer Haidar
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

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,
Sam
 
E Armitage
Rancher
Posts: 989
9
  • 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.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • 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: http://www.coderanch.com/how-to/java/ServletsFaq#security
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE 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.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!