February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-912) Create DirContext is not able to log arrays correctly

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-912: ----------------------------- Affects Version/s: 1.1.0.Beta21 > Create DirContext is not able to log arrays correctly > ----------------------------------------------------- > > Key: ELY-912 > URL: https://issues.jboss.org/browse/ELY-912 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when debug level for class {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder}} is enabled and value of any property from properties used for creating DirContext is array, then its value is not logged correctly, example: > {code} > Property [java.naming.security.credentials] with Value [[C@1bf1b7d5] > {code} > See https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-912) Create DirContext is not able to log arrays correctly

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-912?page=com.atlassian.jira.plugin.sy... ] Ondrej Lukas updated ELY-912: ----------------------------- Component/s: Realms > Create DirContext is not able to log arrays correctly > ----------------------------------------------------- > > Key: ELY-912 > URL: https://issues.jboss.org/browse/ELY-912 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.1.0.Beta21 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > In case when debug level for class {{org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder}} is enabled and value of any property from properties used for creating DirContext is array, then its value is not logged correctly, example: > {code} > Property [java.naming.security.credentials] with Value [[C@1bf1b7d5] > {code} > See https://github.com/wildfly-security/wildfly-elytron/blob/7b5c89c437d27fec... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port

by Daniele Pirola (JIRA)

[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ] Daniele Pirola commented on WFLY-7031: -------------------------------------- Hi Bhaskara, I have the same problem with wildfly 10.1.0.Final behind squid and apache httpd. Finally I modify the {{ajp-listener}} specifying the attribute {{scheme}} like this: {{ <ajp-listener name="ajp" socket-binding="ajp" *scheme="https"*/>}} Now https call works fine and also redirect from http to https. Probably this configuration could be more publicized inside wildfly documentation > Redirect Port Fails to Redirect to 3rd Party HTTP Port > ------------------------------------------------------ > > Key: WFLY-7031 > URL: https://issues.jboss.org/browse/WFLY-7031 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR1 > Reporter: Joe Carder > Assignee: Tomaz Cerar > Priority: Minor > > When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception: > ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8021) JMS-Bridge ignore source-credential-reference attribute

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-8021?page=com.atlassian.jira.plugin.... ] Hynek Švábek reassigned WFLY-8021: ---------------------------------- Assignee: Peter Skopek (was: Darran Lofthouse) > JMS-Bridge ignore source-credential-reference attribute > ------------------------------------------------------- > > Key: WFLY-8021 > URL: https://issues.jboss.org/browse/WFLY-8021 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Peter Skopek > > I catch issue with JMS-Bridge integration with Credential store through credential-reference attribute. > There is problem with source-credential-reference (target-credential-reference works fine). > Problem is that source-credential-reference is ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8021) JMS-Bridge ignore source-credential-reference attribute

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-8021: ---------------------------------- Summary: JMS-Bridge ignore source-credential-reference attribute Key: WFLY-8021 URL: https://issues.jboss.org/browse/WFLY-8021 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse I catch issue with JMS-Bridge integration with Credential store through credential-reference attribute. There is problem with source-credential-reference (target-credential-reference works fine). Problem is that source-credential-reference is ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-904) Logout notification support for HTTP-based authentication mechanisms

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ] Pedro Igor edited comment on ELY-904 at 2/2/17 9:31 PM: -------------------------------------------------------- [~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically. I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. was (Author: pcraveiro): [~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically. I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request for during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. > Logout notification support for HTTP-based authentication mechanisms > -------------------------------------------------------------------- > > Key: ELY-904 > URL: https://issues.jboss.org/browse/ELY-904 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta21 > Reporter: Pedro Igor > Assignee: Pedro Igor > > I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests. > Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases. > The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user. > Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-904) Logout notification support for HTTP-based authentication mechanisms

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ] Pedro Igor commented on ELY-904: -------------------------------- [~darranl], another use case we should keep in mind is mechanisms that rely on cookies which can be removed during logout. Where logout may be triggered programmatically. I've worked on a solution that works for SESSION based mechanisms using notifications. But for cookie-based mechanisms, programmatic logout doesn't work because we process the "responders" right after evaluating a request for during authentication. In this case, notifications can be triggered by the application (e.g.: a servlet + programmatic logout) after responders are processed, what makes impossible to notification listeners write to the response. > Logout notification support for HTTP-based authentication mechanisms > -------------------------------------------------------------------- > > Key: ELY-904 > URL: https://issues.jboss.org/browse/ELY-904 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta21 > Reporter: Pedro Igor > Assignee: Pedro Igor > > I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests. > Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases. > The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user. > Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-904) Logout notification support for HTTP-based authentication mechanisms

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-904?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-904: --------------------------- Summary: Logout notification support for HTTP-based authentication mechanisms (was: Logout support for HTTP-based authentication mechanisms) > Logout notification support for HTTP-based authentication mechanisms > -------------------------------------------------------------------- > > Key: ELY-904 > URL: https://issues.jboss.org/browse/ELY-904 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta21 > Reporter: Pedro Igor > Assignee: Pedro Igor > > I think it makes sense to also allow HTTP mechanisms to handle logouts. Logout is tightly related with authentication and mechanisms should be able to act properly during logout requests. > Although only a few set of mechanisms support logout, I think adding a default method {{org.wildfly.security.http.HttpServerAuthenticationMechanism#logout}} will make our API even more complete and capable of supporting more use cases. > The main use case for this enhancement is programmatic logout. In this case, logout can be triggered from inside an application which in turn delegates the logout logic to the mechanism that authenticated an user. > Considering Elytron Web, this enhancement would make integration with other containers even more simple and avoid dealing with specific logout mechanisms (e.g.: notifications) provided by these same containers. This is specially true for servlet containers. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1935) Add :read-attribute-description operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1935?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1935: ------------------------------------------ I have done quite a lot on this but I think I'll need to shelve it for a while, perhaps until the next release. https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO... There are some edge cases here that need handling, and in a way that's comprehensible to the behavior of other ops. I'm talking about wildcard address handling scenarios. Those will take a bit of thought and it's doubtful I'll get to it before we hit WF Core 3.0.0.Beta1 in a week or so and need to stop feature work. > Add :read-attribute-description operation > ----------------------------------------- > > Key: WFCORE-1935 > URL: https://issues.jboss.org/browse/WFCORE-1935 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Pavel Jelinek > Assignee: Brian Stansberry > Labels: user_experience > > In resource with many attributes which may or may not be ordered in _:read-resource-description_ operation result it's very hard to find description of a particular attribute. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-911) Add method to obtain the request relative path

by Pedro Igor (JIRA)

Pedro Igor created ELY-911: ------------------------------ Summary: Add method to obtain the request relative path Key: ELY-911 URL: https://issues.jboss.org/browse/ELY-911 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Affects Versions: 1.1.0.Beta21 Reporter: Pedro Igor Assignee: Pedro Igor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017