March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11925) Add documentation to the "Using the Elytron Subsystem" on the attributes that can be specified when configuring server and client SSLContexts

by Farah Juma (Jira)

Farah Juma created WFLY-11925: --------------------------------- Summary: Add documentation to the "Using the Elytron Subsystem" on the attributes that can be specified when configuring server and client SSLContexts Key: WFLY-11925 URL: https://issues.jboss.org/browse/WFLY-11925 Project: WildFly Issue Type: Task Components: Security Reporter: Farah Juma Assignee: Farah Juma Add documentation to the "Using the Elytron Subsystem" section on the attributes that can be specified when configuring a {{server-ssl-context}} and a {{client-ssl-context}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11924) Add ability to group distributed session attributes to avoid cost of SESSION granularity

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-11924: ----------------------------------- Summary: Add ability to group distributed session attributes to avoid cost of SESSION granularity Key: WFLY-11924 URL: https://issues.jboss.org/browse/WFLY-11924 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 16.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Since SESSION granularity requires the replication of *all* session attribute if *any* attribute was modified in a given request, most distributed web applications should leverage ATTRIBUTE granularity whenever to possible to reduce the replication payload costs per request. However, if session attribute contains any reference to another session attribute, they are forced to use SESSION granularity to avoid losing referential integrity on failover and duplication of serialized data. The proposal is to allow users the ability to annotate their session attribute classes such that they can group specific attribute together, while still being able to leverage ATTRIBUTE granularity for the remainder of their session attributes. >From the user's perspective, I envision something like this: {code:java} @SessionAttributeGroup("order") public class Order implements Serializable { List<OrderItem> items; } @SessionAttributeGroup("order") public class OrderItem implements Serializable { //... } {code} Thus the code: {code:java} session.setAttribute("order", order); session.setAttribute("customized-item", item); {code} will result in both attributes being store within a single cache entry. Internally, we use the @SessionAttributeGroup as the attribute name, and a Map<String, Object> as the attribute value, keyed by the actual attribute name. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4309) Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4309?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-4309: ------------------------------------- Thanks for this fix, although I am afraid that since issues WFWIP-102 and WFCORE-4302 have not been resolved (and probably will be rejected) the hostname provided has to be entered in a regular expression format. In such case the introduced validation is too strict as even simple escaping characters (double backslash) are not allowed now. In this context, implementation of this needs to be either updated or the introduced validation removed completely. > Value validator for 'host-context-map' attribute of 'server-ssl-sni-context' resource > ------------------------------------------------------------------------------------- > > Key: WFCORE-4309 > URL: https://issues.jboss.org/browse/WFCORE-4309 > Project: WildFly Core > Issue Type: Enhancement > Components: Security > Affects Versions: 7.0.0.Final > Reporter: Jan Stourac > Assignee: Diana Vilkolakova > Priority: Minor > Fix For: 9.0.0.Beta2 > > > There is not validation for 'host-context-map' property values on key side. There is validation for the values that represents 'server-ssl-contexts', although, there is no validation for host matching part. E.g. writing attribute of this value is possible: > {code} > /subsystem=elytron/server-ssl-sni-context=serverSslSniCtx:write-attribute(name=host-context-map,value={"\\?.example.com"=validSslContext,"..example.com"="validSslContext", "\\*\\*.example.com"=validSslContext}) > {code} > {code} > "\\?.example.com" > "..example.com" > "\\*\\*.example.com" > {code} > even though, these are invalid host name matchers IMHO. It would be nice to identify these and report those to user immediately during the configuration attempt. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11923) Elytron JDBC Realm hex encoding and modular crypt support.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11923?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFLY-11923: ------------------------------------ Labels: (was: EAP-CD17) > Elytron JDBC Realm hex encoding and modular crypt support. > ---------------------------------------------------------- > > Key: WFLY-11923 > URL: https://issues.jboss.org/browse/WFLY-11923 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > > This relates to the following issues: - > https://issues.jboss.org/browse/WFCORE-3542 > https://issues.jboss.org/browse/WFCORE-3832 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11923) Elytron JDBC Realm hex encoding and modular crypt support.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11923?page=com.atlassian.jira.plugin... ] Darran Lofthouse moved EAP7-1234 to WFLY-11923: ----------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-11923 (was: EAP7-1234) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: Security (was: Security) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.3.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) Writer: (was: Chuck Copello) > Elytron JDBC Realm hex encoding and modular crypt support. > ---------------------------------------------------------- > > Key: WFLY-11923 > URL: https://issues.jboss.org/browse/WFLY-11923 > Project: WildFly > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Labels: EAP-CD17 > > This relates to the following issues: - > https://issues.jboss.org/browse/WFCORE-3542 > https://issues.jboss.org/browse/WFCORE-3832 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4302) SNI wildcard mappings match multiple level of subdomain

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFCORE-4302?page=com.atlassian.jira.plugi... ] Jan Stourac commented on WFCORE-4302: ------------------------------------- [~mmazanek], I understand your point. Although, actually the correct variant is: {code} host-context-map={".*\\..*\\.example\\.com"=defaultSSC, "[^.]*\\.example\\.com"=asteriskSSC} {code} or simply {code} host-context-map={"[^.]*\\.example\\.com"=asteriskSSC} {code} Yeah... so user has to be aware that he has to provide correct regular expression instead of a simple notation. > SNI wildcard mappings match multiple level of subdomain > ------------------------------------------------------- > > Key: WFCORE-4302 > URL: https://issues.jboss.org/browse/WFCORE-4302 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Final > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Pavel Jelinek > Assignee: Martin Mazanek > Priority: Major > Labels: SNI > > Based on the [text from analasys|https://github.com/wildfly/wildfly-proposals/blob/master/securit...]: > {quote} > Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates. > {quote} > As such, in case I have configured SNI mapping for: > {code} > .*\\.example\\.com > {code} > I expect that this mapping is selected for any single level of subdomain of example.com although, in case of any extra subdomain, this mapping is not utilized. In other words, following hostnames should match: > {code} > test.example.com > another-test.example.com > {code} > although following should not be matched and default server-ssl-context shall be used instead: > {code} > two-sublevel.one-sublevel.example.com > {code} > Current behaviour also matches also 'two-sublevel.one-sublevel.example.com'. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession

by David White (Jira)

[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ] David White commented on JGRP-2299: ----------------------------------- It appears that the NullPointerException that occurs during the unlock operation and the compareTo method in the Owner class is "benign" and can be recovered from. In my application, if I add a try/catch block around the unlock operation and trap the NullPointerException and try the unlock a second time it succeeds. It truly does succeed because our concurrent processes continue and are able to lock/unlock the resource and complete successfully. > LockService does not work correctly if unlock/lock is called in immediate succession > ------------------------------------------------------------------------------------ > > Key: JGRP-2299 > URL: https://issues.jboss.org/browse/JGRP-2299 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.15 > Environment: Windows 10 Oracle JDK 1.8 131 > AIX IBM Java 8 > Reporter: Mirko Streckenbach > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.1 > > Attachments: JGroupsExample.java, udp+lock.xml > > > In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected. > This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded. > If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock(). -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11818) wildfly-16.0.0.Final: "From address" is no more used as default from in email

by Yeray Borges (Jira)

[ https://issues.jboss.org/browse/WFLY-11818?page=com.atlassian.jira.plugin... ] Yeray Borges resolved WFLY-11818. --------------------------------- Resolution: Cannot Reproduce > wildfly-16.0.0.Final: "From address" is no more used as default from in email > ----------------------------------------------------------------------------- > > Key: WFLY-11818 > URL: https://issues.jboss.org/browse/WFLY-11818 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 16.0.0.Final > Environment: mvn -v > Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00) > Maven home: /apps/apache-maven-3.6.0 > Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2 > Default locale: de_DE, platform encoding: UTF-8 > OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix" > Reporter: Wolfgang Mayer > Assignee: Yeray Borges > Priority: Major > > As mentioned in the Help (description) of 'Mail Session' configuration: > From: *From address that is used as default from, if not set when sending* > Apparently this is not the case anymore in wildfly-16.0.0.Final. > For example I made a test with quickstart-16.0/mail/. > When omitting the line > *message.setFrom(new InternetAddress(from));* > Sending mail fails with: > com.sun.mail.smtp.SMTPSendFailedException: 554-Transaction failed > 554 Unauthorized sender address. > I have the same issue when replacing the line above with > message.setFrom(new InternetAddress()); > I am pretty sure that this is working in wildfly-15 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-102) SNI - hostname notation for sni-mapping element does not conform generic rules

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFWIP-102?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFWIP-102: ---------------------------------------- I suspect further changes would be unlikely as this could already be in use on CD releases. > SNI - hostname notation for sni-mapping element does not conform generic rules > ------------------------------------------------------------------------------ > > Key: WFWIP-102 > URL: https://issues.jboss.org/browse/WFWIP-102 > Project: WildFly WIP > Issue Type: Bug > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Way of configuration of {{sni-mapping}} element in {{server-ssl-sni-context}} is not nice from UX and also does not conform the way it is generally used. > With current implementation administrator has to use following notation: > {code} > .*\.example\.com > {code} > This is standard reg-exp notation and is not for easy reading. I think following notation is much better and also is commonly used for this cases: > {code} > *.example.com > {code} > In other words - simple asterisk is used to match any subdomain and dot in our case does not stand for 'any single character'. Note that is the way it was described in [analysis document|https://github.com/wildfly/wildfly-proposals/pull/67/files#diff-...]. > Truth is that with this change we loose some flexibility, e.g. administrator won't be able to configure following: > {code} > www\.exa.ple\.com > {code} > But I doubt this is a common use case. WDYT? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-102) SNI - hostname notation for sni-mapping element does not conform generic rules

by Jan Stourac (Jira)

[ https://issues.jboss.org/browse/WFWIP-102?page=com.atlassian.jira.plugin.... ] Jan Stourac commented on WFWIP-102: ----------------------------------- [~dlofthouse], is it still viable to implement this? If implemented this means necessity of change in some customer configurations. Current behavior has been brought into WildFly 15/JBoss EAP CD15. If we want to change it, then we should do so before EAP7.3 release as any such change in the product is even more problematic, I suppose. My personal opinion on this is that current expected format is not very user friendly. > SNI - hostname notation for sni-mapping element does not conform generic rules > ------------------------------------------------------------------------------ > > Key: WFWIP-102 > URL: https://issues.jboss.org/browse/WFWIP-102 > Project: WildFly WIP > Issue Type: Bug > Environment: Wildfly build with undertow and wildfly-core modules build from following sources: > * https://github.com/stuartwdouglas/undertow/tree/sni > * https://github.com/stuartwdouglas/wildfly-core/tree/sni > Reporter: Jan Stourac > Assignee: Darran Lofthouse > Priority: Major > > Way of configuration of {{sni-mapping}} element in {{server-ssl-sni-context}} is not nice from UX and also does not conform the way it is generally used. > With current implementation administrator has to use following notation: > {code} > .*\.example\.com > {code} > This is standard reg-exp notation and is not for easy reading. I think following notation is much better and also is commonly used for this cases: > {code} > *.example.com > {code} > In other words - simple asterisk is used to match any subdomain and dot in our case does not stand for 'any single character'. Note that is the way it was described in [analysis document|https://github.com/wildfly/wildfly-proposals/pull/67/files#diff-...]. > Truth is that with this change we loose some flexibility, e.g. administrator won't be able to configure following: > {code} > www\.exa.ple\.com > {code} > But I doubt this is a common use case. WDYT? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019