[JBoss JIRA] (ELY-944) Support using CallbackHandler as last resort
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-944:
------------------------------------
Summary: Support using CallbackHandler as last resort
Key: ELY-944
URL: https://issues.jboss.org/browse/ELY-944
Project: WildFly Elytron
Issue Type: Task
Components: Authentication Client
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 1.1.0.Beta26
In many cases where a CallbackHandler is supplied we actually still want credentials already defined on the AuthenticationConfiguration to take priority with the CallbackHandler reserved for user interaction where we do not have a credential.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8099) Define modcluster/ssl vs ssl-context priority
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8099?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-8806 to WFLY-8099:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8099 (was: JBEAP-8806)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: mod_cluster
(was: mod_cluster)
Affects Version/s: (was: 7.1.0.DR11)
> Define modcluster/ssl vs ssl-context priority
> ---------------------------------------------
>
> Key: WFLY-8099
> URL: https://issues.jboss.org/browse/WFLY-8099
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> Specify what should be used if both ssl and ssl-context are set in modcluster subsystem.
> There is no warning that both are set, nor error when ssl-context is different
> It looks that ssl-context has priority
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8098) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
by Aaron Ogburn (JIRA)
Aaron Ogburn created WFLY-8098:
----------------------------------
Summary: ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'
Key: WFLY-8098
URL: https://issues.jboss.org/browse/WFLY-8098
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37
Reporter: Aaron Ogburn
Assignee: Stuart Douglas
When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior:
if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1.
It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port.
We have attached a minimal web application that reproduce this issue.
Also attached is the standalone.xml and the apache configuration file.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8097) Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
by Martin Choma (JIRA)
Martin Choma created WFLY-8097:
----------------------------------
Summary: Coverity static analysis, suspicious bitwise logical expression, DigestUtil (Elytron)
Key: WFLY-8097
URL: https://issues.jboss.org/browse/WFLY-8097
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Critical
Coverity found suspicious logical operation https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=95638...
See detailed description of possible problem in [1]
If I extend DigestUtilTest#testDecodeByteOrderedInteger with case from [1], test fails
{code}
byte[] inputFF = CodePointIterator.ofString("000000FF").hexDecode().drain();
assertEquals(0xFF, decodeByteOrderedInteger(inputFF, 0, 4));
{code}
If I change decodeByteOrderedInteger implementation according to [1], all tests passes.
{code}
result |= (buf[offset + i] & 0xff);
{code}
[1] http://findbugs.sourceforge.net/bugDescriptions.html#BIT_IOR_OF_SIGNED_BYTE
Setting to high priority, because correct behavior of SASL Digest mechanism could be impacted.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8091) Fix Elytron Enabled attributes at DataSources subsystem
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-8091?page=com.atlassian.jira.plugin.... ]
Flavia Rainone updated WFLY-8091:
---------------------------------
Description:
This Jira is for all ELYTRON_ENABLED attributes defined in datasources subsystem.
The attribute definition has two bugs:
- alternatives defined:
The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid. (see more details below)
The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at AbstractDataSourceAdd/XaDataSourceAdd.
- marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now
More details on the alternatives bug:
If elytron-enabled is set to false,we cannot use the other alternatives:
/profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
jndi-name="java:/H2XADS",user-name=sa,password=sa)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
The last command fails with:
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" =>
"WFLYCTL0105: user-name is invalid in combination with
elytron-enabled"},
"rolled-back" => true
}
was:
If elytron-enabled is set to false,we cannot use the other alternatives:
/profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
jndi-name="java:/H2XADS",user-name=sa,password=sa)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
The last command fails with:
/profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" =>
"WFLYCTL0105: user-name is invalid in combination with
elytron-enabled"},
"rolled-back" => true
}
> Fix Elytron Enabled attributes at DataSources subsystem
> -------------------------------------------------------
>
> Key: WFLY-8091
> URL: https://issues.jboss.org/browse/WFLY-8091
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
>
> This Jira is for all ELYTRON_ENABLED attributes defined in datasources subsystem.
> The attribute definition has two bugs:
> - alternatives defined:
> The alternative prevents the user from setting an ELYTRON_ENABLED attribute to false and using one of the alternative attributes, such as SECURITY_DOMAIN because the model will be considered invalid. (see more details below)
> The correct is using alternatives at the AUTHENTICATION_CONTEXT attributes instead and doing an extra validation at AbstractDataSourceAdd/XaDataSourceAdd.
> - marshalling of the attribute, we need to follow the same standard as other boolean attributes in the module, the attribute must be marshalled as a <elytron-enabled>true</elytron-enabled> instead of <elytron-enabled/>, which is the current form being used now
> More details on the alternatives bug:
> If elytron-enabled is set to false,we cannot use the other alternatives:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:add(driver-name=h2,
> jndi-name="java:/H2XADS",user-name=sa,password=sa)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=password)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:undefine-attribute(name=user-name)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=elytron-enabled,value=false)
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> The last command fails with:
> /profile=full/subsystem=datasources/xa-data-source=H2XADS:write-attribute(name=user-name,value=sa)
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" =>
> "WFLYCTL0105: user-name is invalid in combination with
> elytron-enabled"},
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months