Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

regarding security

 
krishna prasad gunasekaran
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
authentication and authorization can be developed in servlet and xml.
which one is best & flexible?

hava a nice day
krishna prasad
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 64967
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic