[JBoss JIRA] (WFLY-7244) Web sockets are always enabled
by Kabir Khan (JIRA)
Kabir Khan created WFLY-7244:
--------------------------------
Summary: Web sockets are always enabled
Key: WFLY-7244
URL: https://issues.jboss.org/browse/WFLY-7244
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Kabir Khan
Assignee: Stuart Douglas
Fix For: 11.0.0.Alpha1
TCK testing for WFLY-6784 unearthed that websockets were always turned on in the undertow subsystem, while they should be explicitly turned on with the websocket element.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7243) Web sockets are always enabled
by Kabir Khan (JIRA)
Kabir Khan created WFLY-7243:
--------------------------------
Summary: Web sockets are always enabled
Key: WFLY-7243
URL: https://issues.jboss.org/browse/WFLY-7243
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Kabir Khan
Assignee: Stuart Douglas
Fix For: 11.0.0.Alpha1
TCK testing for WFLY-6784 unearthed that websockets were always turned on in the undertow subsystem, while they should be explicitly turned on with the websocket element.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1310?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1310:
-----------------------------------
Attachment: RuleTest.java
Standalone JUnit reproducer for the case.
> Expired fact with activationCount > 0 are not evicted from objectstore
> ----------------------------------------------------------------------
>
> Key: DROOLS-1310
> URL: https://issues.jboss.org/browse/DROOLS-1310
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.CR2
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: RuleTest.java
>
>
> Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual.
> Sized-down reproducer will be submitted at a later time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Michał Nowakowski commented on WFLY-7229:
-----------------------------------------
@Paul: I'll try. We can disable server-side invalidation without losing security or functionality, but we're concerned about resources. Our interval has to be closer to 20 minutes than 20 seconds, and our sessions are not minute. Plus, no appserver we used before was having any problem with this invalidation, nor with being given valid cookies to invalid sessions - these were Tomcat, JBossAS and older versions of WF. I guess people that wrote CAS client for Java were also unaware of any. Or... is handling a HttpSession in context of a _foreign_ HttpRequest (that is, a request of a different session or with no session at all) still faithful to the spec?
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2104?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2104.
----------------------------
Resolution: Done
> NAMING: provide logical names when IpAddressUUID is used as addresses
> ---------------------------------------------------------------------
>
> Key: JGRP-2104
> URL: https://issues.jboss.org/browse/JGRP-2104
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
> If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
> {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
> Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2104?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2104:
---------------------------
Description:
This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
{{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
was:
This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
{{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
> NAMING: provide logical names when IpAddressUUID is used as addresses
> ---------------------------------------------------------------------
>
> Key: JGRP-2104
> URL: https://issues.jboss.org/browse/JGRP-2104
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
> If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
> {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
> Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7193:
--------------------------------
Assignee: Jan Kalina
> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
> Key: WFLY-7193
> URL: https://issues.jboss.org/browse/WFLY-7193
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Martin Choma commented on ELY-627:
----------------------------------
Also note, there should be possible to configure protocols like "openssl.TLS" introduced by https://issues.jboss.org/browse/WFCORE-1757.
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-673) Elytron Integration with Core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-673:
------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> Elytron Integration with Core
> -----------------------------
>
> Key: WFCORE-673
> URL: https://issues.jboss.org/browse/WFCORE-673
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha10
>
>
> This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks.
> In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
> https://issues.jboss.org/issues/?filter=12323574
> The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
> The general criteria for the resolution of this issue will be: -
> - Inclusion of the Elytron Subsystem in core
> - All network entry points in core to be securable using Elytron
> - All SSL artefacts to be obtainable from Elytron.
> Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months