April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8507) :resolve-path provides wrong path if attribute "path" contains absolute path

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-8507?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-10125 to WFLY-8507: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8507 (was: JBEAP-10125) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Affects Version/s: (was: 7.1.0.DR14) > :resolve-path provides wrong path if attribute "path" contains absolute path > ---------------------------------------------------------------------------- > > Key: WFLY-8507 > URL: https://issues.jboss.org/browse/WFLY-8507 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > If attribute {{path}} for paging-directory is set as absolute and {{relative-to}} is undefined: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path, value=/tmp/paging-journal) > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/path=paging-directory:undefine-attribute(name=relative-to) > :reload > {code} > then {{:resolve-path}} returns concatenation of old {{relative-to}} and {{path}}: > {code} > [standalone@localhost:9990 /] /subsystem=messaging-activemq/server=default/path=paging-directory:resolve-path > { > "outcome" => "success", > "result" => "/home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/server1/jboss-eap/standalone/data//tmp/paging-journal" > } > {code} > Undefining attribute {{relative-to}} does not work. Also if {{path}} contains absolute path then relative-to is not ignored. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1342) Lazy Enlistment expects active transaction

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1342?page=com.atlassian.jira.plugin... ] Stefano Maestri resolved JBJCA-1342. ------------------------------------ Resolution: Done > Lazy Enlistment expects active transaction > ------------------------------------------ > > Key: JBJCA-1342 > URL: https://issues.jboss.org/browse/JBJCA-1342 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Reporter: Flavia Rainone > Assignee: Flavia Rainone > > Lazy enlistment fails when there is no active transaction: > javax.resource.ResourceException: IJ000652: Unable to obtain lock > org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.lazyEnlist(TxConnectionManagerImpl.java:820) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-717) Creating Credentail Store from scratch when keystore file exists is successful.

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-717?page=com.atlassian.jira.plugin.sy... ] Peter Skopek closed ELY-717. ---------------------------- Resolution: Rejected Use the same storage file for two credential stores is clearly a user mistake we cannot suppress. Only use case would be if someone would like to use it with modifiable = "false" which prevents the file of being modified. > Creating Credentail Store from scratch when keystore file exists is successful. > ------------------------------------------------------------------------------- > > Key: ELY-717 > URL: https://issues.jboss.org/browse/ELY-717 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Peter Skopek > > When I want to create new Credential Store from scratch and keystore file exists is successful. > In my opinion right behaviour is failure. > For behaviour like this when multiple Credential Stores use one keystore file I don't need use parameter "create.storage=true". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ] Ondrej Lukas commented on WFCORE-2615: -------------------------------------- There is lack of documentation that we do not know how the final list of supported mechanisms on client side should be created. Javadoc for allow-sasl-mechanisms is: _Create a new configuration which is the same as this configuration, but which explicitly allows only the given named mechanisms. Any unlisted mechanisms will not be supported unless the configuration supports it._ XSD about allow-sasl-mechanisms says: _List of SASL mechanisms to be used unless specifically forbidden._ [~dmlloyd] We have following questions: * Could you please provide us an information how the final list of supported mechanisms on client side is created? * What is "the configuration" from last sentence of javadoc? * If definition is the same as you said in your previous comment, why authentication-configuration provides attribute {{allow-all-mechanisms}}? > Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration > ---------------------------------------------------------------------------------- > > Key: WFCORE-2615 > URL: https://issues.jboss.org/browse/WFCORE-2615 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta10 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: dep.war, wireshark.pcapng > > > In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms. > See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce". > This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client. > We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1056) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1056?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev moved WFCORE-2618 to ELY-1056: -------------------------------------------- Project: WildFly Elytron (was: WildFly Core) Key: ELY-1056 (was: WFCORE-2618) Affects Version/s: (was: 3.0.0.Beta11) > CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1056 > URL: https://issues.jboss.org/browse/ELY-1056 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > > Without --location parameter a credential store storage file isn't saved (or save as is expected). > It pass but I am not able find credential store storage file on disk. > {code} > [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > It pass with this URI value and I am able to find credential store storage file on disk. > {code} > uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" > {code} > I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha... > (test.store is interpreded as hostname in URI in first case) > *NOTE* > Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. > Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-426) Auto more/less in CLI for multi-page output

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-426?page=com.atlassian.jira.plugin... ] Jean-Francois Denise commented on WFCORE-426: --------------------------------------------- Implemented on top of the move to aesh-readline: https://github.com/jfdenise/wildfly-core/commit/ba63b4c533701ddc80188ddbd... Small impact, output collector flushed at the end of any command and prior to prompt user. PR to come once readline branch is merged. > Auto more/less in CLI for multi-page output > ------------------------------------------- > > Key: WFCORE-426 > URL: https://issues.jboss.org/browse/WFCORE-426 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > Where the result of a management operation in the CLI returns multiple screens of output it would be nice if this could be automatically wrapped in a more/less type behaviour. > Similar to how git handles git log compared to how svn handles svn log. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8501) Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-8501?page=com.atlassian.jira.plugin.... ] Kabir Khan reopened WFLY-8501: ------------------------------ > Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22 > ---------------------------------------------------- > > Key: WFLY-8501 > URL: https://issues.jboss.org/browse/WFLY-8501 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8501) Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-8501?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-8501. ------------------------------ Resolution: Done > Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22 > ---------------------------------------------------- > > Key: WFLY-8501 > URL: https://issues.jboss.org/browse/WFLY-8501 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8506) Elytron SPNEGO authentication in deployment over HTTPS, EAP requests for HTTPS/hostname ticket.

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8506?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-10122 to WFLY-8506: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8506 (was: JBEAP-10122) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR15) > Elytron SPNEGO authentication in deployment over HTTPS, EAP requests for HTTPS/hostname ticket. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-8506 > URL: https://issues.jboss.org/browse/WFLY-8506 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Priority: Blocker > Labels: eap71_beta_candidate, kerberos, spnego, tls > > Accessing deployment secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/hostname. > See network dump krb_https_deployment.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured. > If I configure HTTPS/hostname in KDC and kerberos credential factory to use principal HTTPS/hostname it works correctly. But I still believe it is bug: > * At least it is not consistent with legacy management interface behaviour (JBEAP-8572). > * found 2 sources describing protocol and service does not match 1:1 and for https protocol HTTP/hostname SPN should be used [1][2] > [1] https://sites.google.com/a/chromium.org/dev/developers/design-documents/h... > [2] https://support.microsoft.com/en-us/help/929650/how-to-use-spns-when-you-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1054) CS tool, There is possibility add EMPTY alias name and EMPTY secret value to credential store storage file through wildfly-elytron-tool.

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-1054?page=com.atlassian.jira.plugin.s... ] Ilia Vassilev reassigned ELY-1054: ---------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > CS tool, There is possibility add EMPTY alias name and EMPTY secret value to credential store storage file through wildfly-elytron-tool. > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1054 > URL: https://issues.jboss.org/browse/ELY-1054 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > > There is possibility add EMPTY alias name and EMPTY secret value to credential store storage file through wildfly-elytron-tool. > I expect consistent behaviour as through CLI where isn't possible to do it. > *How to reproduce* > {code} > java -jar wildfly-elytron-tool.jar credential-store --add="" --secret="" --location="/tmp/store02.jceks" --uri "cr-store://store02.jceks?modifiable=true;create=true;keyStoreType=JCEKS" -p pass123 > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 April 2017