November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-747) Is SSLContextAuthenticationConfiguration Still required now sslRules are separated.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-747?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-747: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > Is SSLContextAuthenticationConfiguration Still required now sslRules are separated. > ----------------------------------------------------------------------------------- > > Key: ELY-747 > URL: https://issues.jboss.org/browse/ELY-747 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta16 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-730) Enhance IdentityCredentials to be iterable

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-730?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-730: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > Enhance IdentityCredentials to be iterable > ------------------------------------------ > > Key: ELY-730 > URL: https://issues.jboss.org/browse/ELY-730 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta16 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-728) The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-728: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. > ------------------------------------------------------------------------------------------ > > Key: ELY-728 > URL: https://issues.jboss.org/browse/ELY-728 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta16 > > > This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-726) Default Mechanism Ordering Implementation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-726?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-726: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > Default Mechanism Ordering Implementation > ----------------------------------------- > > Key: ELY-726 > URL: https://issues.jboss.org/browse/ELY-726 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta16 > > > We have to have some form of mechanism ordering anyway to get silent mechanisms to the front of the queue. > SaslMechanismInformation may need some updates but we have plenty of information about the mechanisms so we should be able to put together a reasonable documented ordering. > Stronger mechanisms that can complete without interaction with the client can be pulled up the list as they can quickly silently fail where AuthenticationClient does not have enough information to handle them. This set probably includes JBOSS_LOCAL_USER, EXTERNAL, GSSAPI, GS2, and the token mechs. > For username / password mechanisms we can ensure PLAIN goes last. > Of the CRAM, Digest, and SCRAM set I would suggest first order by digest algorithm and then SCRAM -> Digest -> CRAM. > There will be the opportunity for plenty of discussions on is X really better than Y but I think a reasonable default implementation that is documented will be much better than today's current random ordering. Once filtering has been applied to take into account things like available credentials in the realms etc. > I would expect most lists to be very small, maybe some silent mechs a token mech and one or two username / password mechs depending on consistency of an identity store. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-681: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > Hide private packages from generated javadoc. > --------------------------------------------- > > Key: ELY-681 > URL: https://issues.jboss.org/browse/ELY-681 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta16 > > > We may want two profiles so we can generate a full javadoc and a 'public' javadoc. > The 'public' javadoc should be the default one generated and should exclude the following packages: - > org.wildfly.security._private > org.wildfly.security.asn1 > org.wildfly.security.auth.realm > org.wildfly.security.auth.realm.* > org.wildfly.security.authz.jacc > org.wildfly.security.credential.store.impl > org.wildfly.security.security.digest > org.wildfly.security.http.impl > org.wildfly.security.security.keystore > org.wildfly.security.mechanism.oauth2 > org.wildfly.security.mechanism.scram > org.wildfly.security.password.impl > org.wildfly.security.password.util > org.wildfly.security.pem > org.wildfly.security.sasl > org.wildfly.security.sasl.* (Except util) > org.wildfly.security.util > org.wildfly.security.util_private > org.wildfly.security.x500 > org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-722) Move callback handler interactions to a common base class for HTTP mechanisms, .

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-722?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-722: --------------------------------- Fix Version/s: 1.1.0.Beta16 (was: 1.1.0.Beta15) > Move callback handler interactions to a common base class for HTTP mechanisms,. > ------------------------------------------------------------------------------- > > Key: ELY-722 > URL: https://issues.jboss.org/browse/ELY-722 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta16 > > > This is to follow a similar pattern as is used for the SASL mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-785) Release WildFly Elytron 1.1.0.Beta15

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-785?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-785. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta15 > ------------------------------------ > > Key: ELY-785 > URL: https://issues.jboss.org/browse/ELY-785 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2038) Update CLI to use aesh-readline 1.0

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2038?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-2038: ---------------------------------- Description: Today CLI uses aesh 0.66.\+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.\+ library is going to be split into 2 libraries: 1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C). 2) aesh 1.0, based on aesh-readline containing the console and the Command API. It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite. So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline. The benefits are: - Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1% - Less tricks in the CLI code to support prompting users (userName, password). - Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues. - aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline. - aesh-readline should consume less memory and be more reactive. The risks: - aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass). was: Today CLI uses aesh 0.66.+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.+ library is going to be split into 2 libraries: 1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C). 2) aesh 1.0, based on aesh-readline containing the console and the Command API. It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite. So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline. The benefits are: - Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1% - Less tricks in the CLI code to support prompting users (userName, password). - Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues. - aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline. - aesh-readline should consume less memory and be more reactive. The risks: - aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass). > Update CLI to use aesh-readline 1.0 > ----------------------------------- > > Key: WFCORE-2038 > URL: https://issues.jboss.org/browse/WFCORE-2038 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Today CLI uses aesh 0.66.\+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.\+ library is going to be split into 2 libraries: > 1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C). > 2) aesh 1.0, based on aesh-readline containing the console and the Command API. > It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite. > So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline. > The benefits are: > - Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1% > - Less tricks in the CLI code to support prompting users (userName, password). > - Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues. > - aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline. > - aesh-readline should consume less memory and be more reactive. > The risks: > - aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2038) Update CLI to use aesh-readline 1.0

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2038: -------------------------------------------- Summary: Update CLI to use aesh-readline 1.0 Key: WFCORE-2038 URL: https://issues.jboss.org/browse/WFCORE-2038 Project: WildFly Core Issue Type: Enhancement Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Today CLI uses aesh 0.66.+. This branch is not going to evolve. aesh project is moving away from this branch. Legacy aesh 0.66.+ library is going to be split into 2 libraries: 1) aesh-realine 1.0, the foundations (terminal, character handling, history, user interaction such as Enter, TAB, Ctrl-C). 2) aesh 1.0, based on aesh-readline containing the console and the Command API. It happens that CLI is using today only a subset of aesh 0.66.+. This subset is similar to what aesh-readline is offering. I say similar because aesh-readline is a complete rewrite. So it makes sense, in order to follow aesh evolutions, to rewrite the CLI aesh integration and rely on aesh-readline. The benefits are: - Blocking API. No more active polling in CLI (used to be around 1% CPU activity). That will be 0.1% - Less tricks in the CLI code to support prompting users (userName, password). - Help aesh project to evolve the aesh-readline API (feature and quality). We are the main consumer of this API and we come with a bunch of usage contexts that reveal issues. - aesh (The console and API), that we will use in CLI.next will benefit from any improvement we are doing today in aesh-readline. - aesh-readline should consume less memory and be more reactive. The risks: - aesh-readline is mainly tested by the CLI integration. There are not (yet) intensive usage of aesh-readline. So we can expect some regressions (although 100% of unit tests will pass). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler

by ted won (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ] ted won updated WFCORE-2011: ---------------------------- Issue Type: Enhancement (was: Bug) > Inconsistency of formatter and named-formatter in console logging handler > ------------------------------------------------------------------------- > > Key: WFCORE-2011 > URL: https://issues.jboss.org/browse/WFCORE-2011 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha13 > Environment: It is possible to reproduce with all profiles and all modes. > All WildFly profiles > All WildFly clustering mode > * standalone mode > * domain mode > Reporter: ted won > Assignee: ted won > Priority: Minor > Labels: logging > Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png > > > In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter. > And the COLOR-PATTERN named-formatter is defined with: {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} > It is working as it is defined with colors in a console. > {code:title=standalone.xml} > ... > <subsystem xmlns="urn:jboss:domain:logging:3.0"> > <console-handler name="CONSOLE"> > <level name="INFO"/> > <formatter> > <named-formatter name="COLOR-PATTERN"/> > </formatter> > </console-handler> > ... > <formatter name="COLOR-PATTERN"> > <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/> > </formatter> > </subsystem> > ... > {code} > However there is a inconsistency in the CLI and WildFly admin console views. > In the CLI, CONSOLE formatter is: {noformat}"%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"{noformat} It is wrong and different with the working logging format in a console. > {code:title=JBoss CLI} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n", > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} > It should be fixed like below: > {code:title=Expected result} > [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource > { > "outcome" => "success", > "result" => { > "autoflush" => true, > "enabled" => true, > "encoding" => undefined, > "filter" => undefined, > "filter-spec" => undefined, > "formatter" => undefined, > "level" => "INFO", > "name" => "CONSOLE", > "named-formatter" => "COLOR-PATTERN", > "target" => "System.out" > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2016