Users may be confused about what I'm answering here, because the previous ghost was posted while Mehdii resolves differences with the Ranch administration, but I feel like it's important that everyone should know the answers to these questions:
Mehdii Hafid wrote:
I'm actually very happy with my design. Having programmatic sign up, login, logout in the
same Bean is OK .So I don't see the point of separating
login, logout and sign up.
Authentication and user registration are two
very different things. For example, when you authenticate, you don't write to the database, whereas by definition when you "sign up" you are writing, By placing these two functions in the same module, you have made it so that if an attacker can subvert the login code, that person has a direct route to the user administration services and can thereby potentially wreak major havoc.
A
really secure system wouldn't even have the user administration functions in the same webapp, but would hand over control to a different app so that the primary app could use a database connection that had fewer security rights than the app that managed user accounts did.
Aside from that, when you're using J2EE container security, the webapp doesn't need a database connection to the user credentials at all. That's handled by the Realm. So you're adding database connectivity to an otherwise innocent module.
Mehdii Hafid wrote:
Tim Holloway wrote:Thirdly, the bean is far too knowledgeable about HTTP and JSF internals.
is that supposed to be a bad thing?
Yes it is.
1. JSF is designed to be a JavaBeans-oriented framework that does most of its work by Inversion of Control. In short, an "ideal" JSF backing bean is so generic that you can
reuse the entire bean in a
non-web application. Failing that, at a minimum you should avoid coding any references to resources that aren't in the javax.faces.model packages wherever possible.
2. As I mentioned previously, not using resources that are only available in a live webapp server (HTTP and JSF) means that you can unit-test the bean offline. This saves a lot of development time (== money) and makes maintenance simpler.
3. The JSF internals have already undergone major changes in times past. There are definitely some things I'd like to see fixed in some future version of JSF. By abstracting the functions that only JSF or J2EE can provide to an external support module, it's possible to "future proof" the bean code. It's a lot easier (== less time/money) to change interfaces in my JSFUtils module than it would be to have to hunt down and change every JSF backing bean that used JSF or J2EE internal services.
Consider this: Struts was an early attempt to create a Model/View/Controller framework in J2EE for the web. Struts required developers to implement certain interfaces and to subclass certain classes. Objects designed for Struts were useless outside of Struts and changes to Struts required changes to otherwise innocent application code. The creators of Struts realized that this was expensive and painful and quite a few of them were later part of the group that designed JSF. The pain that they had suffered is why JSF is based on POJOs and not specialized classes. JSF does have some specialized classes, of course, such as custom validators, but these are adjuncts to the JSF Controllers. not part of the application's core UI and business functionality.
Actually, the initiall design for JSF not only didn't assume that only HTML was an option (back then, cheaper smartphones didn't use HTML), but JSF also didn't assume that it would only be used for webapps or even on the Internet. They had more of a portable GUI platform in mind that could work in places where the Java desktop GUI systems like AWT and Swing didn't apply. It's only that in actual practice that web and HTML are the primary uses for JSF, and you never know - someday that may change. After all, who uses Gopher on the Internet anymore?