[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3422) Add basic method on Identity that checks for authenticated user
[
https://jira.jboss.org/jira/browse/JBSEAM-3422?page=com.atlassian.jira.pl...
]
Shane Bryzak commented on JBSEAM-3422:
--------------------------------------
So the crux of the issue is that developers would prefer to call a simple method (without
any parameters) rather than use identity.isLoggedIn(false) ? That seems fair enough,
however I'm hesitant to add a method called isAuthenticated() to do this -
semantically, it's equivalent to isLoggedIn() (i.e. someone who is logged in is
_always_ going to be authenticated).
I think I would rather do something like deprecate the isLoggedIn(boolean) method, leaving
isLoggedIn() to check if the user is already authenticated (without attempting a login)
and create a new method along the lines of tryLogin() which would perform the login
attempt.
Re. the duplicate message/authentication problem, this involved more than setting the
password to null - in 2.1.0 the credentials can become "invalid" (i.e. Identity
calls credentials.invalidate() if the supplied credentials didn't result in successful
authentication). If the credentials have been invalidated in this way then an
authentication attempt won't be repeated. We could port this stuff to 2.0 if we
really wanted to, however I think we need to draw the line somewhere and the duplicate
authentication behaviour is already clearly documented in the security chapter.
Add basic method on Identity that checks for authenticated user
---------------------------------------------------------------
Key: JBSEAM-3422
URL: https://jira.jboss.org/jira/browse/JBSEAM-3422
Project: Seam
Issue Type: Feature Request
Components: Security
Affects Versions: 2.0.3.CR1, 2.1.0.BETA1
Reporter: Dan Allen
Assignee: Dan Allen
Priority: Minor
Fix For: 2.0.3.CR2, 2.1.0.CR1
Original Estimate: 5 minutes
Remaining Estimate: 5 minutes
People often report the their authentication method is called more than once. While there
are many different conditions that can lead to this problem, the most common is developers
using #{identity.loggedIn} for conditional rendering in the UI.
Contrary to popular understanding, the #{identity.loggedIn} (alternatively written as
#{identity.isLoggedIn()}) is not a simple JavaBean-style accessor method. It will attempt
to perform a login if the user is not currently authenticated, thus making this method
unsuitable to be used in the UI for conditional rendering. While nothing troublesome
happens on successful login, when the login fails, or a guest user is browsing a page that
calls this method, Seam triggers the authentication method at these arbitrary points in
time.
A very simple workaround is use either #{identity.isLoggedIn(false)} or to simply create
a new method on the identity component that merely checks if the user principal is null or
non-null.
public boolean isAuthenticated() {
return getPrincipal() != null;
}
In the UI you can now use #{identity.authenticated}, which is now the preferred way to
check if the user has a security principal.
Note: You only see the double message if you add a FacesMessage in the authenticate
method. If you use Seam's built in authentication messages, you don't get the
double message because the quietLogin() method (called by isLoggedIn()) skips adding the
messages. You aren't privy to the information of whether the authentication method was
called by quietLogin() for your own message registration purposes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira