aspose file tools*
The moose likes Servlets and the fly likes regarding security Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "regarding security" Watch "regarding security" New topic
Author

regarding security

krishna prasad gunasekaran
Ranch Hand

Joined: Jul 25, 2006
Posts: 158
authentication and authorization can be developed in servlet and xml.
which one is best & flexible?

hava a nice day
krishna prasad


have a great day,
krishna prasad
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Both


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

Best? That's pretty subjective.

Flexible? I'd say editing an xml file was easier than recoding, compiling and deploying a Servlet. Although I guess even in the xml, you'd still have to redeploy.

I think the whole idea of security constraints in deployment descriptors is to minimize the amount of security code you'd have to put in a Servlet. It's best if a Servlet acts as a business controller, as opposed to a security guard.

Nevertheless, there are things you can do in code that you can't do in the deployment descriptor. Still, I go for xml based.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Kameron McKenzie:
Best? That's pretty subjective.

Flexible? I'd say editing an xml file was easier than recoding, compiling and deploying a Servlet. Although I guess even in the xml, you'd still have to redeploy.

I think the whole idea of security constraints in deployment descriptors is to minimize the amount of security code you'd have to put in a Servlet. It's best if a Servlet acts as a business controller, as opposed to a security guard.

Nevertheless, there are things you can do in code that you can't do in the deployment descriptor. Still, I go for xml based.


Generally, when one chooses programmatic security over declaritive security in a Java EE app, it is because the user information is (or is going to be) stored in the application's core database (in other words, the user security is part of the app's data). In this case, it's easier to have the security become part of the app, as opposed to a server configuration setting.

If, in your situation, it makes more sense to decouple the user security from the mechanics of the app itself then declarative security might make more sense.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61413
    
  67

Originally posted by Ben Souther:

If, in your situation, it makes more sense to decouple the user security from the mechanics of the app itself then declarative security might make more sense.


Though personally, I have rarely found it to be so.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Bear Bibeault:


Though personally, I have rarely found it to be so.


We have some upload tools and file manager type apps that don't otherwise need a relational database. For these it is much more convenient to use the declarative security mechanism provided by the container.

Otherwise, same here.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: regarding security