[JBoss JIRA] (JGRP-2163) Potential NPE in TP.handleProbe
by Zoltan Farkas (JIRA)
Zoltan Farkas created JGRP-2163:
-----------------------------------
Summary: Potential NPE in TP.handleProbe
Key: JGRP-2163
URL: https://issues.jboss.org/browse/JGRP-2163
Project: JGroups
Issue Type: Bug
Reporter: Zoltan Farkas
Assignee: Bela Ban
Priority: Minor
at:
https://github.com/belaban/JGroups/blob/3.6/src/org/jgroups/protocols/TP....
{code}
public Map<String, String> handleProbe(String... keys) {
Map<String,String> retval=new HashMap<>(keys != null? keys.length : 2);
for(String key: keys) {
{code}
keys is checked for null and on the next line it is de-refferenced...
this code fill fail with NPE if keys is null...
This issue is discovered by findbugs NP_NULL_ON_SOME_PATH check. Highly recommend running findbugs + coverity (free for OS projects).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2527) There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2527?page=com.atlassian.jira.plugi... ]
Hynek Švábek resolved WFCORE-2527.
----------------------------------
Resolution: Rejected
This behaviour is correct. No relative-to path have default value.
> There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server.
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2527
> URL: https://issues.jboss.org/browse/WFCORE-2527
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
> Priority: Critical
>
> There is set wrong default *relative-to* path for CredentialStore.
> Default *relative-to* path is set to folder from which we started EAP server.
> e.g.:
> * cd EAP_FOLDER
> * ./bin/standalone.sh
> * relative-to is se to EAP_FOLDER
> or
> * cd EAP_FODER/bin
> * ./standalone.sh
> * relative-to is se to EAP_FOLDER/bin
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/keystorecs007.jceks?create=true", credential-reference= {clear-text=pass123})
> {code}
> {code}
> /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron)
> {code}
> Now you can see in EAP_FOLDER (it can be different, see above) keystorecs007.jceks file.
> I would expect this file in data directory of server.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (ELY-524) RealmIdentity data caching support in the LDAP realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-524:
---------------------------------
Fix Version/s: 1.1.0.Beta31
(was: 1.1.0.Beta30)
> RealmIdentity data caching support in the LDAP realm
> ----------------------------------------------------
>
> Key: ELY-524
> URL: https://issues.jboss.org/browse/ELY-524
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Realms
> Reporter: David Lloyd
> Assignee: Pedro Igor
> Priority: Critical
> Fix For: 1.1.0.Beta31
>
>
> The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic.
> The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention.
> For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes.
> Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name.
> This is a complex design topic so discussion is welcome.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month