[JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=*
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-8428.
-------------------------------
Fix Version/s: 11.0.0.Beta1
Resolution: Done
> :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=*
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-8428
> URL: https://issues.jboss.org/browse/WFLY-8428
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Harald Pehl
> Assignee: Tomaz Cerar
> Fix For: 11.0.0.Beta1
>
>
> The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}:
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true)
> {
> "outcome" => "failed",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFLY-778) Only one deployed application can use custom mailcap
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-778?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar reassigned WFLY-778:
--------------------------------
Assignee: (was: Tomaz Cerar)
> Only one deployed application can use custom mailcap
> ----------------------------------------------------
>
> Key: WFLY-778
> URL: https://issues.jboss.org/browse/WFLY-778
> Project: WildFly
> Issue Type: Bug
> Components: EE, Mail
> Environment: AS 7, many applications deployed with custom mailcaps.
> Reporter: Philippe Guinot
> Priority: Minor
> Labels: activation, javax, mail, mailcap, mailcapcommandmap
>
> In the MailcapCommandMap class, it loads the mailcap file only once. This may cause troubles when different applications use different custom mailcap.
> Also, if no mailcap is found in the current class loader, only ONE mailcap file from the module will be loaded, and not all of them, which is an issue if we get the mail-dsn jar added in the javax.mail.api module.
> If there is only one application deployed, adding in the jboss-deployement-structure.xml the following dependency:
> {code:xml}<module name="javax.mail.api"><imports><include path="META-INF"/><include path="META-INF/**"/></imports></module>{code}
> and, from the application, calling at startup:
> {code}javax.activation.CommandMap.setDefaultCommandMap(new MailcapCommandMap());{code}
> cause the loading of all mailcap files found from the current class loader (those of the application + those of javax.mail.api module).
> But, if there are more than one application deployed, only the first to do so will have its mailcap loaded.
> The design of javax.activation should be changed to take in account this side-effect of isolation: what happen if 2 applications define different classes for the same type/mime ??
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months