[JBoss JIRA] (WFCORE-2385) There are two different error messages for adding duplicate record to CS by same command.
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2385?page=com.atlassian.jira.plugi... ]
Michal Petrov updated WFCORE-2385:
----------------------------------
Git Pull Request: https://github.com/wildfly-security-incubator/wildfly-core/pull/113 (was: https://github.com/wildfly/wildfly-core/pull/2301)
> There are two different error messages for adding duplicate record to CS by same command.
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-2385
> URL: https://issues.jboss.org/browse/WFCORE-2385
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Michal Petrov
>
> There are two different error messages for adding duplicate record to CS by same command.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/customcredCS007.jceks?create.storage=true", credential-reference={clear-text=pass123})
> {code}
> {code}
> /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret)
> {code}
> And now we try add there same alias with exactly same name and with name in uppercase
> {code}
> /subsystem=elytron/credential-store=cs007/alias=alias001:add(secret-value=secret)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"elytron\"),
> (\"credential-store\" => \"cs007\"),
> (\"alias\" => \"alias001\")
> ]",
> "rolled-back" => true
> }
> {code}
> {code}
> /subsystem=elytron/credential-store=cs007/alias=ALIAS001:add(secret-value=secret)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store",
> "rolled-back" => true
> }
> {code}
> You can see different error message.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (WFLY-8483) Upgrade IronJacamar to 1.4.3 from 1.4.2
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/WFLY-8483?page=com.atlassian.jira.plugin.... ]
Stefano Maestri moved JBEAP-10059 to WFLY-8483:
-----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8483 (was: JBEAP-10059)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JCA
(was: JCA)
Fix Version/s: (was: 7.1.0.DR12)
> Upgrade IronJacamar to 1.4.3 from 1.4.2
> ---------------------------------------
>
> Key: WFLY-8483
> URL: https://issues.jboss.org/browse/WFLY-8483
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JCA
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> This is needed to adjust the SPI needed for the Elytron integration for the three JCA subsystems
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1338:
-------------------------------------
New PR with solution #2 from previous post: https://github.com/ironjacamar/ironjacamar/pull/623
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1338:
-------------------------------------
Commit was rolled back due to this regression: https://issues.jboss.org/browse/JBEAP-9730
Some analysis:
# The change I'd made set {{autocommit = true}} on the jdbc connection and reset the {{underlyingAutoCommit}} var in the {{BaseWrapperManagedConnection#cleanup()}} method:
{code}
BaseWrapperManagedConnection#cleanup():
jdbcAutoCommit = true;
+ if (jdbcAutoCommit != underlyingAutoCommit)
+ {
+ try {
+ con.setAutoCommit(jdbcAutoCommit);
+ underlyingAutoCommit = jdbcAutoCommit;
+ } catch (SQLException e) {
+ mcf.log.errorResettingAutoCommit(mcf.getJndiName(), e);
+ }
+ }
{code}
# That broke following fix in the {{destroy()}} method, which depended on {{underlyingAutoCommit}} var:
{code}
BaseWrapperManagedConnection#destroy():
// See JBAS-5678
if (!underlyingAutoCommit)
con.rollback();
{code}
so the connection was not rolled back on destroy caused by a connection error and the transaction somehow got committed.
*But* that actually wasn't the reason why the test failed, as this fix is probably only relevant to Oracle db, which apparently commits a transaction when closing the connection (JBAS-5678).
# The reason of the test failure is that postgresql driver commits a running transaction when autocommit is set to true:
{code}
PgConnection:
public void setAutoCommit(boolean autoCommit) throws SQLException {
checkClosed();
if (this.autoCommit == autoCommit) {
return;
}
if (!this.autoCommit) {
commit();
}
this.autoCommit = autoCommit;
}
{code}
# Also related - normally if a transaction is left open and a managed connection is closed, the transaction is closed in {{TxConnectionListener.tidyup()}}. That doesn't happen if the connection is closed due to connection error:
{code}
AbstractConnectionManager#returnManagedConnection():
if (!kill && cl.getState().equals(ConnectionState.NORMAL))
{
cl.tidyup();
}
{code}
Possible solutions:
# Continue with the old fix, just add {{con.rollback()}} before {{con.setAutoCommit(true)}} in the {{cleanup()}} method.
# Rather then in the cleanup method, we could reset autocommit state in {{BaseWrapperManagedConnectionFactory#getInvalidConnections()}} just before validating the connection, where there should be no running transaction present...
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-1145:
-------------------------------
Fix Version/s: 3.0.0.Beta13
(was: 3.0.0.Beta12)
> Review of HostController / Application Server Remoting connections
> ------------------------------------------------------------------
>
> Key: WFCORE-1145
> URL: https://issues.jboss.org/browse/WFCORE-1145
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron, domain-mode
> Fix For: 3.0.0.Beta13
>
>
> Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access.
> The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years