[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 11:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Nobody/Anonymous (nobody)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 02:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
>Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
>Comment By: Scott M Stark (starksm)
Date: 2002-10-24 07:30
Message:
Logged In: YES
user_id=175228
The context in which refresh is allowed is correct. A lookup of
a user's roles requires the cache info to exist due to a
previous authentication. The only way accessing the role can
return null is if the cache has been flushed after
authentication by an admin, or another thread has failed to
authenticate the user. What is the context in which you see
the null roles returned?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 11:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
>Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-25 14:39
Message:
Logged In: YES
user_id=618121
Yes, I see that now. I was misled by the term "cache".
The problem is not that the cache is null, but that the
cacheInfo.roles is null. This seems to be the default behaviour
if incorrect credentials are submitted, but is also happens
sometimes if the correct credentials are submitted. Maybe
only if incorrect credentials has been submitted earlier (at
least it's hard to reproduce in another way). Once it happens
that user won't get the roles back until the server is restarted.
Flushing the cache does not help, in fact it makes it
impossible to login for anyone.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-24 16:30
Message:
Logged In: YES
user_id=175228
The context in which refresh is allowed is correct. A lookup of
a user's roles requires the cache info to exist due to a
previous authentication. The only way accessing the role can
return null is if the cache has been flushed after
authentication by an admin, or another thread has failed to
authenticate the user. What is the context in which you see
the null roles returned?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
---
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
___
Jboss-development mailing list
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 11:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-10-25 20:31
Message:
Logged In: YES
user_id=366650
This might be the problem that causes RunAsLoginModule not
to work. It doesn't work because there is principal=null.
--
Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-25 14:39
Message:
Logged In: YES
user_id=618121
Yes, I see that now. I was misled by the term "cache".
The problem is not that the cache is null, but that the
cacheInfo.roles is null. This seems to be the default behaviour
if incorrect credentials are submitted, but is also happens
sometimes if the correct credentials are submitted. Maybe
only if incorrect credentials has been submitted earlier (at
least it's hard to reproduce in another way). Once it happens
that user won't get the roles back until the server is restarted.
Flushing the cache does not help, in fact it makes it
impossible to login for anyone.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-24 16:30
Message:
Logged In: YES
user_id=175228
The context in which refresh is allowed is correct. A lookup of
a user's roles requires the cache info to exist due to a
previous authentication. The only way accessing the role can
return null is if the cache has been flushed after
authentication by an admin, or another thread has failed to
authenticate the user. What is the context in which you see
the null roles returned?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
---
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 02:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
>Comment By: Scott M Stark (starksm)
Date: 2002-10-25 13:08
Message:
Logged In: YES
user_id=175228
That makes no sense. Flushing the cache resets the
security domain state to its startup state. Describe how you
can achieve a state where no one can login even after the
cache is flushed.
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-10-25 11:31
Message:
Logged In: YES
user_id=366650
This might be the problem that causes RunAsLoginModule not
to work. It doesn't work because there is principal=null.
--
Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-25 05:39
Message:
Logged In: YES
user_id=618121
Yes, I see that now. I was misled by the term "cache".
The problem is not that the cache is null, but that the
cacheInfo.roles is null. This seems to be the default behaviour
if incorrect credentials are submitted, but is also happens
sometimes if the correct credentials are submitted. Maybe
only if incorrect credentials has been submitted earlier (at
least it's hard to reproduce in another way). Once it happens
that user won't get the roles back until the server is restarted.
Flushing the cache does not help, in fact it makes it
impossible to login for anyone.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-24 07:30
Message:
Logged In: YES
user_id=175228
The context in which refresh is allowed is correct. A lookup of
a user's roles requires the cache info to exist due to a
previous authentication. The only way accessing the role can
return null is if the cache has been flushed after
authenticat
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 11:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
>Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-28 00:11
Message:
Logged In: YES
user_id=618121
The problem was a combination of the following:
- JAAS not always finding the client login config because i'm
running through WebStart which uses it's own class loader
which was not set as the context class loader
- ClientLoginModule using the old callback handler even if a
new one is submitted:
LoginContext("client-login",
new CallbackHandler("misspelledname","pw")).
login();
LoginContext("client-login",
new CallbackHandler("correctedname","pw")).
login();
will use the first handler also the second timenot wrong,
only surprising, to me at least.
- The accidential server-side execution of some code involved
in setting up the client login configuration.
Thanks for your time.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-25 22:08
Message:
Logged In: YES
user_id=175228
That makes no sense. Flushing the cache resets the
security domain state to its startup state. Describe how you
can achieve a state where no one can login even after the
cache is flushed.
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-10-25 20:31
Message:
Logged In: YES
user_id=366650
This might be the problem that causes RunAsLoginModule not
to work. It doesn't work because there is principal=null.
--
Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-25 14:39
Message:
Logged In: YES
user_id=618121
Yes, I see that now. I was misl
[JBoss-dev] [ jboss-Bugs-627892 ] getUserRoles incorrectly returns null
Bugs item #627892, was opened at 2002-10-24 02:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=627892&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jon S Bratseth (bratseth)
Assigned to: Scott M Stark (starksm)
Summary: getUserRoles incorrectly returns null
Initial Comment:
See the first posting on this at
http://www.jboss.org/forums/thread.jsp?
forum=49&thread=23370
The problem is that JaasSecurityManager.getUserRoles
returns null when it should have returned the pricipals
roles:
[code]
public Set getUserRoles(Principal principal)
{
HashSet userRoles = null;
Subject subject = getActiveSubject();
if( subject != null )
{
DomainInfo info = getCacheInfo(principal, false);
Group roles = null;
if( info != null )
roles = info.roles;
if( roles != null )
{
userRoles = new HashSet();
Enumeration members = roles.members();
while( members.hasMoreElements() )
{
Principal role = (Principal)
members.nextElement();
userRoles.add(role);
}
}
}
return userRoles;
}
[/code]
This is an obfuscated way of saying
if theres cached roles ( getCacheInfo(..).roles ),
return them
else
return null
And when getCacheInfo is called with parameter false, it
will peek() the cache, and thus not fetch the object if it's
not present.
Thus, if there's no cached roles, the roles returned for
the principal is null.
This can't be what is intended, but how to correct it?
I could simply pass true instead of false to switch to get
() instead of peek(), but the JavaDoc of getCacheInfo
warns about an error on getCacheInfo(..,true) which
seesms to be to be the error one would get on sending
false:
[code]
/** An accessor method that synchronizes access on
the domainCache
to avoid a race condition that can occur when the
cache entry expires
in the presence of multi-threaded access. The
allowRefresh flag should
be true for authentication accesses and false for
authorization accesses.
If it were to be true for an authorization access a
previously authenticated
user could be seen to not have their expected
permissions due to a cache
expiration.
@param principal, the caller identity whose cached
credentials are to
be accessed.
@param allowRefresh, a flag indicating if the cache
access should flush
any expired entries.
*/
private DomainInfo getCacheInfo(Principal principal,
boolean allowRefresh)
{
if( domainCache == null )
return null;
DomainInfo cacheInfo = null;
synchronized( domainCache )
{
if( allowRefresh == true )
cacheInfo = (DomainInfo) domainCache.get
(principal);
else
cacheInfo = (DomainInfo) domainCache.peek
(principal);
}
return cacheInfo;
}
[/code]
Is the problem simply that the cases which should allow
refresh and thos which should have been mixed up?
--
>Comment By: Scott M Stark (starksm)
Date: 2002-10-29 21:08
Message:
Logged In: YES
user_id=175228
Maybe this is not really an issue of a problem on the client
but another manifestation of bug #630616. Test your scenario
against the latest 3.0 cvs code to see if the fix for that helps
here.
--
Comment By: Jon S Bratseth (bratseth)
Date: 2002-10-27 15:11
Message:
Logged In: YES
user_id=618121
The problem was a combination of the following:
- JAAS not always finding the client login config because i'm
running through WebStart which uses it's own class loader
which was not set as the context class loader
- ClientLoginModule using the old callback handler even if a
new one is submitted:
LoginContext("client-login",
new CallbackHandler("misspelledname","pw")).
login();
LoginContext("client-login",
new CallbackHandler("correctedname","pw")).
login();
will use the first handler also the second timenot wrong,
only surprising, to me at least.
- The accidential server-side execution of some code involved
in setting up the client login configuration.
Thanks for your time.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-25 13:08
Message:
Logged In: YES
user_id=175228
That makes no sense. Flushing the cache resets the
security domain state to its startup state. Describe how you
can achieve a state where no one can login even after the
cache is flushed.
--
Comment By: Marius Kotsbak (mkotsbak)
Date: 2002-10-25 11:3
