May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.s... ] Jan Kalina resolved ELY-1444. ----------------------------- Fix Version/s: 1.4.0.CR1 Assignee: Jan Kalina Resolution: Duplicate Issue Support of hex encoding added in ELY-1582. > Jdbc-realm with simple digest mapper > ------------------------------------ > > Key: ELY-1444 > URL: https://issues.jboss.org/browse/ELY-1444 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Affects Versions: 1.2.0.Beta9 > Reporter: Martin Choma > Assignee: Jan Kalina > Fix For: 1.4.0.CR1 > > > This is inspired by ELY-1435, but in this case trying simple digest hash. > In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8 > I get these values by http://passwordsgenerator.net/sha256-hash-generator/ > {noformat} > 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser]. > 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm] > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser] > 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser > 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed. > 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6803) Add multi-server support to mod_cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6803?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6803: --------------------------------- Affects Version/s: 13.0.0.Final 12.0.0.Final 11.0.0.Final > Add multi-server support to mod_cluster > --------------------------------------- > > Key: WFLY-6803 > URL: https://issues.jboss.org/browse/WFLY-6803 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster > Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 14.0.0.CR1 > > > Currently, mod_cluster subsystem supports only a single configuration, which references the default undertow server. However, Undertow supports multiple servers, and exposes a distinct route capability per server (see WFLY-6778). mod_cluster should therefore support multiple "profiles", where each profile references a specific undertow server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6803) Add multi-server support to mod_cluster

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6803?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6803: --------------------------------- Fix Version/s: 14.0.0.CR1 > Add multi-server support to mod_cluster > --------------------------------------- > > Key: WFLY-6803 > URL: https://issues.jboss.org/browse/WFLY-6803 > Project: WildFly > Issue Type: Feature Request > Components: mod_cluster > Affects Versions: 10.0.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 14.0.0.CR1 > > > Currently, mod_cluster subsystem supports only a single configuration, which references the default undertow server. However, Undertow supports multiple servers, and exposes a distinct route capability per server (see WFLY-6778). mod_cluster should therefore support multiple "profiles", where each profile references a specific undertow server. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1596) Verify all permission checks on public API are documented in the Javadoc

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1596: ------------------------------------- Summary: Verify all permission checks on public API are documented in the Javadoc Key: ELY-1596 URL: https://issues.jboss.org/browse/ELY-1596 Project: WildFly Elytron Issue Type: Task Components: API / SPI Reporter: Darran Lofthouse We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1596) Verify all permission checks on public API are documented in the Javadoc

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1596?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1596: ---------------------------------- Description: We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/index... was:We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. > Verify all permission checks on public API are documented in the Javadoc > ------------------------------------------------------------------------ > > Key: ELY-1596 > URL: https://issues.jboss.org/browse/ELY-1596 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > > We have methods such as the following where a permission check occurs but the Javadoc does not describe the required permission so an end user would only discover this by trial and error. > http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/index... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1584) Add ability to log security manager violations to out-of-band log file

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1584?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on ELY-1584: --------------------------------------- Slightly related to this I think there have been things attempted in the past for the security manager to log in a format that could be fed back into a security policy allowing a user to run their app and identify the permissions is needed. > Add ability to log security manager violations to out-of-band log file > ---------------------------------------------------------------------- > > Key: ELY-1584 > URL: https://issues.jboss.org/browse/ELY-1584 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Security Manager > Reporter: David Lloyd > > It would be useful for CI if we could set a system property which would log security manager permission check violations (and the details thereof) to a log file, outside of the standard log infrastructure. This would potentially allow us to fail CI when unexpected "hidden" permission violations occur by way of a post-build script analyzes the log output. > This might also be useful for troubleshooting more obscure security manager related problems. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1584) Add ability to log security manager violations to out-of-band log file

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1584?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1584: --------------------------------- [~dmlloyd] what exactly mean "outside of the standard log infrastructure" ? We already have DEBUG messages in *org.wildfly.security.access*: {code} 17:15:03,705 DEBUG (main) [org.wildfly.security.access] <WildFlySecurityManager.java:226> Permission check failed (permission "("java.io.FilePermission" "/home/jkalina/work/wildfly-elytron/target/test-classes/org/junit/runner/notification/RunNotifier$7.class" "read")" in code source "(file:/home/jkalina/work/wildfly-elytron/target/classes/ <no signer certificates>)" of "sun.misc.Launcher$AppClassLoader@18b4aac2") {code} jboss logger allows to redirect it into standalone log file - is not it sufficient? > Add ability to log security manager violations to out-of-band log file > ---------------------------------------------------------------------- > > Key: ELY-1584 > URL: https://issues.jboss.org/browse/ELY-1584 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Security Manager > Reporter: David Lloyd > > It would be useful for CI if we could set a system property which would log security manager permission check violations (and the details thereof) to a log file, outside of the standard log infrastructure. This would potentially allow us to fail CI when unexpected "hidden" permission violations occur by way of a post-build script analyzes the log output. > This might also be useful for troubleshooting more obscure security manager related problems. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10489) mod_cluster listener attribute is still called "connector"

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-10489?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-10489: ---------------------------------- Description: mod_cluster listener attribute is still called "connector" which is confusing. The goal is to rename this to listener. > mod_cluster listener attribute is still called "connector" > ---------------------------------------------------------- > > Key: WFLY-10489 > URL: https://issues.jboss.org/browse/WFLY-10489 > Project: WildFly > Issue Type: Enhancement > Components: mod_cluster > Affects Versions: 13.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > mod_cluster listener attribute is still called "connector" which is confusing. > The goal is to rename this to listener. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10489) mod_cluster listener attribute is still called "connector"

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-10489: ------------------------------------- Summary: mod_cluster listener attribute is still called "connector" Key: WFLY-10489 URL: https://issues.jboss.org/browse/WFLY-10489 Project: WildFly Issue Type: Enhancement Components: mod_cluster Affects Versions: 13.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10488) Upgrade WildFly HTTP Client to 1.0.13.Final

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-10488?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-10488: ------------------------------------ /cc [~swd847] > Upgrade WildFly HTTP Client to 1.0.13.Final > ------------------------------------------- > > Key: WFLY-10488 > URL: https://issues.jboss.org/browse/WFLY-10488 > Project: WildFly > Issue Type: Component Upgrade > Reporter: David Lloyd > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 4 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 May 2018