• 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

Right approach in creating password protected webapp

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello, I was wondering if someone could give me some pointers how to create a password protected webapp "the right way".

At the moment I have all the .jsp's hidden in WEB-INF/jsp so they can only be accessed via actions.

I got a login action that sets ...



... if the given username/password was valid.

Every .jsp uses the same header.jsp and inside the header I have



Any flaws with this kind of design ?

How about protecting the actions ? Meaning that if someone manages to figure out that new users are created with adminCreateNewUser.do -action and calls it directly. The <logic:notPresent> in the header.jsp doesn't help because it is called after the action has been run.

Should I add something like ...



... to every single action I have ?

Thanks.
[ December 21, 2005: Message edited by: Nems Vedek ]
 
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The action is the place to check for valid login, not the JSP. As you mentioned, a lot of processing can take place before a jsp is ever displayed.

Each action must do the check for a valid login, but there are ways to avoid coding the check in every action. One way would be to create a subclass of org.apache.struts.action.Action that does the check and have each of your actions extend this base action. Another way would be to put the logic in a method in a utility class and call the utility method in every action.

Another way would be to code the login check as a filter and have all URLs except the login action itself covered by that filter.
[ December 21, 2005: Message edited by: Merrill Higginson ]
 
Nems Vedek
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


The action is the place to check for valid login, not the JSP.



Yes, this is the way I've been doing it.


Each action must do the check for a valid login, but there are ways to avoid coding the check in every action. One way would be to create a subclass of org.apache.struts.action.Action that does the check and have each of your actions extend this base action.



This sounds like a good idea.


Another way would be to put the logic in a method in a utility class and call the utility method in every action.



At the moment I have foo.mypackage.common- package that holds all kinds of utility stuff for filtering strings/converting dates etc.

Was just wondering is it better to have all the common methods for the webapp in one class or should I seperate the methods to own classes.

I mean like put all the filtering related stuff to one class and login related to another etc.
[ December 22, 2005: Message edited by: Nems Vedek ]
 
Merrill Higginson
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think there's a right or wrong answer to your question. It's mostly a matter of preference. If there are 20 methods in the class, I'd refactor and break them up into logical units. If there are only a few methods, I wouldn't worry about refactoring.
 
reply
    Bookmark Topic Watch Topic
  • New Topic