September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFBUILD-27) wildfly-server-provisioning-maven-plugin does not extract symlinks correctly

by Alex Szczuczko (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-27?page=com.atlassian.jira.plugin... ] Alex Szczuczko commented on WFBUILD-27: --------------------------------------- I've traced this issue to FileUtils.extractFile(), which doesn't consider symlinks at all. The symlinks fall through the special conditions, and are then treated as normal files, leading to the observed behaviour of a file with a single line of text. Unfortunately the JDK's ZipFile library is being used there, and there's no way to make that work with symlinks. I'm working on a solution using Apache's commons-compress. > wildfly-server-provisioning-maven-plugin does not extract symlinks correctly > ---------------------------------------------------------------------------- > > Key: WFBUILD-27 > URL: https://issues.jboss.org/browse/WFBUILD-27 > Project: WildFly Build Tools > Issue Type: Bug > Reporter: Alex Szczuczko > Assignee: Stuart Douglas > > In Keycloak, I have a feature pack with content that includes semantic links. When wildfly-server-provisioning-maven-plugin's build goal is called during a subsequent maven build, it extracts the feature pack, but the semantic links are not correctly created. > Instead of an actual symlink, a single line file is created that contains the target of the symlink. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-27) wildfly-server-provisioning-maven-plugin does not extract symlinks correctly

by Alex Szczuczko (JIRA)

Alex Szczuczko created WFBUILD-27: ------------------------------------- Summary: wildfly-server-provisioning-maven-plugin does not extract symlinks correctly Key: WFBUILD-27 URL: https://issues.jboss.org/browse/WFBUILD-27 Project: WildFly Build Tools Issue Type: Bug Reporter: Alex Szczuczko Assignee: Stuart Douglas In Keycloak, I have a feature pack with content that includes semantic links. When wildfly-server-provisioning-maven-plugin's build goal is called during a subsequent maven build, it extracts the feature pack, but the semantic links are not correctly created. Instead of an actual symlink, a single line file is created that contains the target of the symlink. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-708) Elytron key-store with WrongPassword is replace with zero size file when I process "store" operation over CLI.

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-708?page=com.atlassian.jira.plugin.sy... ] Farah Juma resolved ELY-708. ---------------------------- Resolution: Out of Date Resolving this one since the corresponding JBEAP issue was resolved. > Elytron key-store with WrongPassword is replace with zero size file when I process "store" operation over CLI. > -------------------------------------------------------------------------------------------------------------- > > Key: ELY-708 > URL: https://issues.jboss.org/browse/ELY-708 > Project: WildFly Elytron > Issue Type: Bug > Components: KeyStores > Affects Versions: 1.1.0.Beta11 > Reporter: Hynek Švábek > > When I create elytron key-store with wrong password and execute *store* operation > /subsystem=elytron/key-store=firefly:store() > then the key-store file is replace with zero size.file. > I can see this error message > {code} > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: password can't be null", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-890) Please remove CredentialStore name from CredentialStore URI attribute.

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-890?page=com.atlassian.jira.plugin.sy... ] Farah Juma resolved ELY-890. ---------------------------- Resolution: Out of Date Resolving this one since the corresponding JBEAP issue was resolved (it was out of date due to JBEAP-6907). > Please remove CredentialStore name from CredentialStore URI attribute. > ---------------------------------------------------------------------- > > Key: ELY-890 > URL: https://issues.jboss.org/browse/ELY-890 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > > Please remove CredentialStore name from CredentialStore URI attribute. > {code} > cr-store://testName/cs002.jceks > {code} > The name (testName) from URI atrribute is used only in parser for this URI. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-633) No log messages comming from Elytron - password verification

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-633?page=com.atlassian.jira.plugin.sy... ] Farah Juma resolved ELY-633. ---------------------------- Resolution: Out of Date Resolving this one since the corresponding JBEAP issue was resolved as out of date. > No log messages comming from Elytron - password verification > ------------------------------------------------------------ > > Key: ELY-633 > URL: https://issues.jboss.org/browse/ELY-633 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > > Elytron is missing any log messages related to password verification. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1261) Revisit credentials key-store-reference and certificate from Elytron client configuration file

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1261?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1261. ----------------------------- Resolution: Rejected Resolving this one since the corresponding JBEAP issue was rejected (it was decided that key-store-reference and certificate didn't need to be removed). > Revisit credentials key-store-reference and certificate from Elytron client configuration file > ---------------------------------------------------------------------------------------------- > > Key: ELY-1261 > URL: https://issues.jboss.org/browse/ELY-1261 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Priority: Critical > > It seems that only supported SASL mechanism in Elytron which is able to work with key/certificate is {{EXTERNAL}} mechanism. However this mechanism takes this information from SSL connection which means that credentials defined in {{configuration.authentication-client.authentication-configurations.configuration.credentials.key-store-reference}} or {{configuration.authentication-client.authentication-configurations.configuration.credentials.certificate}} from Elytron client configuration file are not used in this case. > Is there any Elytron supported SASL mechanism which is currently able to work with these credentials? In this case please provide configuration and SASL mechanism which is able to work with {{key-store-reference}} and {{certificate}} credentials. > Otherwise these {{key-store-reference}} and {{certificate}} should be removed from Elytron client configuration because they currently cannot be used by users (or tested by QA). They can be added to configuration again once Elytron will support mechanism which is able to work with key/certificate as credentials. This is basically the similar issue as ELY-1257. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1257) Remove credentials key-pair and public-key-pem from Elytron client configuration file

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1257?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1257. ----------------------------- Resolution: Rejected Resolving this issue since the corresponding JBEAP issue was rejected (it was decided that key-pair and public-key-pem didn't need to be removed). > Remove credentials key-pair and public-key-pem from Elytron client configuration file > ------------------------------------------------------------------------------------- > > Key: ELY-1257 > URL: https://issues.jboss.org/browse/ELY-1257 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta52 > Reporter: Ondrej Lukas > Priority: Critical > > Based on following discussion with [~dmlloyd]: > {quote} > > - key-pair - what is the reason for this credential element? How it can be used? > This is for key-based authentication mechanisms, like SSH. We're also > developing a key-based SASL mechanism [1] that will hopefully make some > progress in the next quarter (and is open to contribution from all). > > - public-key-pem - I do not understand reason of this credentials on client side. I would be able to understand private-key-pem. Is this element correct or should be removed? > A public key could be used for the purposes of server verification. We > don't yet have a way to establish a means to authenticate servers > though, other than using a trust store; this is something that will > probably be developed in conjunction with [1]. > [1] https://github.com/dmlloyd/pk-rfc > {quote} > we suggest to remove {{key-pair}} and {{public-key-pem}} from {{configuration.authentication-client.authentication-configurations.configuration.credentials}} in Elytron client configuration file. We can introduce those credentials once it will be implemented. Provided credentials for mechanisms which are currently not supported in Elytron can be confusing and can result in incorrect client configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-544) Field clientCertUrl from EntitySaslClient is always null

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-544?page=com.atlassian.jira.plugin.sy... ] Farah Juma resolved ELY-544. ---------------------------- Fix Version/s: 1.2.0.Beta3 Resolution: Duplicate Issue > Field clientCertUrl from EntitySaslClient is always null > -------------------------------------------------------- > > Key: ELY-544 > URL: https://issues.jboss.org/browse/ELY-544 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta5 > Reporter: Ondrej Lukas > Priority: Minor > Labels: static_analysis > Fix For: 1.2.0.Beta3 > > > Field {{clientCertUrl}} from org.wildfly.security.sasl.entity.EntitySaslClient is always null which causes that method getClientCertificate() includes deadcode - condition {{clientCertUrl != null}} is always false. Is it intended? Feel free to close this issue as not a bug if this is currently intended behavior. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-630) Elytron - aggregate-role-mapper can contain multi reference to one role mapper

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-630?page=com.atlassian.jira.plugin.sy... ] Farah Juma resolved ELY-630. ---------------------------- Resolution: Rejected Resolving this one since the corresponding JBEAP issue was rejected (since calling the same mapper multiple times in the chain should be allowed). > Elytron - aggregate-role-mapper can contain multi reference to one role mapper > ------------------------------------------------------------------------------ > > Key: ELY-630 > URL: https://issues.jboss.org/browse/ELY-630 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Hynek Švábek > Priority: Minor > > Aggregate-role-mapper can contain multi reference to one role mapper. > In my opinion it isn't valid state. > But there is some probability that it is required behaviour. > Can you have a look on it? > Configuration snippet: > {code} > <subsystem xmlns="urn:wildfly:elytron:1.0"> > <mappers> > <add-prefix-role-mapper name="CreaperTestAddPrefixRoleMapper" prefix="somePrefix"/> > <aggregate-role-mapper name="CreaperTestAggregateRoleMapper"> > <role-mapper name="CreaperTestAddPrefixRoleMapper"/> > <role-mapper name="CreaperTestAddPrefixRoleMapper"/> > </aggregate-role-mapper> > </mappers> > </subsystem> > {code} > *Actual results:* > Aggregate-role-mapper can contain multi reference to one role-mapper. > *Expected results:* > You would not be able to define multi reference to one role-mapper in aggregate-role-mapper. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1192) HTTP status 500 when no principal is returned by aggregate-principal-transformer

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1192?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1192. ----------------------------- Resolution: Out of Date Resolving this one since the corresponding JBEAP issue was resolved. > HTTP status 500 when no principal is returned by aggregate-principal-transformer > -------------------------------------------------------------------------------- > > Key: ELY-1192 > URL: https://issues.jboss.org/browse/ELY-1192 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > > In case security domain used by deployed application uses {{aggregate-principal-transformer}} which includes some {{principal-transformers}} and none of them returns non-null principal then HTTP status 500 with 'ELY01003: No authentication is in progress' is returned by application. It causes that authentication cannot be repeated (e.g. when user provides some typo in username). It should rather throw HTTP status 401 to allow repeating authentication process. > This situation can happen if {{aggregate-principal-transformer}} is used as decision tree (see [1] for details) and uses only transformers which can return null principal (e.g. only chained-principal-transformers). > This happens when {{aggregate-principal-transformer}} is used in {{pre-realm-principal-transformer}} for security domain. It does not happen when {{aggregate-principal-transformer}} is used in {{principal-transformer}} for realm in security domain. > [1] https://issues.jboss.org/browse/JBEAP-9628?focusedCommentId=13399462&page... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 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 September 2017