[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3422) Add basic method on Identity that checks for authenticated user
5:54 a.m.
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
Affects Versions: 2.1.0.BETA1, 2.0.3.CR1
Reporter: Dan Allen
Assignee: Dan Allen
Priority: Minor
Fix For: 2.0.3.CR2, 2.1.0.CR1
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
7:31 a.m.
New subject: [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...
]
Dan Allen commented on JBSEAM-3422:
-----------------------------------
Quoting Shane Bryzak:
"The authentication-method-being-called-more-than-once bug is fixed in Seam 2.1.0
with the refactoring out of the Credentials class from Identity. I'd prefer not to
add another method to Identity just to check if the user is logged in - if the user's
credentials haven't been set then a login won't be attempted, so calling
Identity.isLoggedIn() should be safe in this regards."
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
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
7:33 a.m.
New subject: [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...
]
Dan Allen commented on JBSEAM-3422:
-----------------------------------
While I see the changes, the fact is there is still a case for a method that does the
extremely simple task of checking whether the principal is null (but having a semantic
name so it is meaningful to the developer).
Here is the use case. Put a login form on the page, then under the login form put a
fragment that uses rendered="#{identity.loggedIn}". What you will discover is
that during the update models phase, each portion of the tree is touched and since the
rendered check occurs further down in the tree than the login form, the credentials are
set when the tree walker gets there. Since the invoke application phase hasn't
happened yet, the login attempt occurs in the update models phase, which is really not
what the developer is intending to have happen. Thus, it is a very bad idea to use the
isLoggedIn() method to bind into the UI component tree. It would be *so* much simpler just
to have a method like #{identity.authenticated}. Trust the developers will like this.
Several have told me as much.
I noticed that you solved the duplicate message problem by clearing the password in the
public void authenticate(LoginContext loginContext) throws LoginException; method on
Identity. Any reason why this cannot be applied to branch 2.0?
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
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
12:22 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (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...
]
Dan Allen updated JBSEAM-3422:
------------------------------
Component/s: Security
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
1:04 a.m.
New subject: [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
3:35 a.m.
New subject: [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...
]
Dan Allen commented on JBSEAM-3422:
-----------------------------------
Yes! That's a perfect solution. isLoggedIn() making a login attempt is what is not
semantically correct. If we make that a simple check, then I don't think we need any
other change to the API. We already have login() and quietLogin(), so what else do we
need?
The conclusion here is to have isLoggedIn() do what it is intended for, which is to check
if the login has already succeeded.
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
4:40 a.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (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 closed JBSEAM-3422.
--------------------------------
Fix Version/s: (was: 2.0.3.CR2)
Resolution: Done
Assignee: Shane Bryzak (was: Dan Allen)
I've made these changes in SVN, hopefully it won't break anyone's app (I
tested the changes and there seemed to be no adverse affect) however since it's for a
major release we're allowed to break some stuff ;)
I've also made a note of the changes in seam21migration.txt.
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: Shane Bryzak
Priority: Minor
Fix For: 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
5762
days inactive
5768
days old
6 comments
2 participants
participants (2)
-
Dan Allen (JIRA) -
Shane Bryzak (JIRA)