[
https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.sy...
]
Paul Ferraro commented on ELY-957:
----------------------------------
[~mchoma] The purpose of moving the synchronized modifier to an internal synchronized
block is not meant to change the behavior - just the signature of the public methods.
I'm not sure what you mean by "future implementations" being safe. The
DefaultSingleSignOn and DefaultSingleSignOnEntry objects are an implementation detail of
the DefaultSingleSignOnManager implementation. Any implementation of SingleSignOnManager
is free to enforce whatever threading constraints it wants/needs.
e.g.
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
Coverity static analysis: DefaultSingleSignOn.getIdentity() not
synchronized
----------------------------------------------------------------------------
Key: ELY-957
URL:
https://issues.jboss.org/browse/ELY-957
Project: WildFly Elytron
Issue Type: Bug
Components: HTTP
Affects Versions: 1.1.0.Beta24
Reporter: Martin Choma
Assignee: Paul Ferraro
Priority: Minor
Coverity static-analysis scan found getter is not synchronized, while setter is.
{code}
public SecurityIdentity getIdentity() {
return this.entry.getCachedIdentity().getSecurityIdentity();
}
{code}
Current implementation is correct because in DefaultSingleSignOnEntry (currently only
avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile.
However other implementations can be wrongly implemented. Once getIdentity() would be
marked with synchronize modifier, such problem shouldn't occure.
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=84908...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)