[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Jeanne Boyarsky:
James,
The stateless local bean provides you the benefits of the EJB container - security, transaction support, etc.
but security from what?
Example: You dont want your employee to invoke the method setSalary() but you want your manager to be able to do it.
Originally posted by James Ellis:
OK I hear this kind of talk about security all the time and I've never quite thought it made much sense. Maybe because I focus mostly on web applications...but why would an employee ever be logged into the portion of a site that would allow them to call setSalary()?
Originally posted by James Ellis:
Also, can you give me a real life business case when you'd need a transaction that doesn't involve some sort of state?
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
If the employee is a programming geek and knows the JNDI lookup for the bean and can access the methods that can affect a production database... yikes. Hypothetical situation but may happen. Your application may have admin roles and methods which only admins should be able to invoke. Security is useful then. You are right in that the user should never be given a link to "setSalary.do?sal=200000" but nothing will can stop him/her from putting it into their address bars.
First line of defense is to configure the security for URLs declaratively. Then set security for beans if neccessary.
If you have configured security for URLs declaratively (as you suggested)...then the link to "setSalary.do?sal=200000" wouldn't do anything since the URL itself would be blocked.