[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-6263:
------------------------------
Component/s: EE
Web (Undertow)
> Apostrophe in an attribute with multiple EL parts breaks function lookup
> ------------------------------------------------------------------------
>
> Key: WFLY-6263
> URL: https://issues.jboss.org/browse/WFLY-6263
> Project: WildFly
> Issue Type: Bug
> Components: EE, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Paul Pogonyshev
> Assignee: Jason Greene
> Priority: Critical
> Attachments: jastow-bug.war.zip, jastow.diff
>
>
> Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between.
> This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10.
> Example is attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2186) Salted password cannot be set through CLI for Elytron filesystem-realm identity
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2186?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2186:
----------------------------------------------
[~michpetrov], I have looked at how to implement this support. If you are not already working on it, I can take ownership of this issue.
JF
> Salted password cannot be set through CLI for Elytron filesystem-realm identity
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2186
> URL: https://issues.jboss.org/browse/WFCORE-2186
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha16
> Reporter: Ondrej Lukas
> Assignee: Michal Petrov
>
> Password encryption/hash mechanisms which contain {{salt}} attribute for filesystem-realm identity cannot be added through CLI. {{set-password}} operation fails and finishes with failure-description "WFLYCTL0155: password may not be null" even if password was set. It seems when {{salt}} attribute with {{bytes}} value is used then {{password}} attribute is ignored by CLI.
> Following password encryption/hash mechanisms from filesystem-realm identity are affected by issue:
> - {{bcrypt}}
> - {{salted-simple-digest}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-869) Elytron security realms cannot be used only for authorization
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-869?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-869:
--------------------------------
To be able full use of AggregationRealm we need to allow authorization (obtaining roles) for users, which does not exists in given realm - when the user exists in JDBCRealm and in LdapRealm we have groups (with usernames in member-like attribute), we need to be able obtain the groups.
But current design of Realm interface say, we need to have authentication identity (RealmIdentity) before we can obtain authorization identity - we cannot obtain identity attributes when getRealmIdentity() say the identity does not exists.
a) Should not this be redesigned?
b) For now I can workaround it for LdapRealm - when user will not define search-dn/name-filter, user entity will not be searched (will be supposed it exists) and only filtered attributes will be possible to obtain from LDAP - would you agree with that solution of this issue?
> Elytron security realms cannot be used only for authorization
> -------------------------------------------------------------
>
> Key: ELY-869
> URL: https://issues.jboss.org/browse/ELY-869
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta18
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: print-roles.war
>
>
> Scenario: I try to configure application server for scenario when different identity stores are used for authentication and authorization (e.g. username/password are stored in LDAP and roles are assigned from Database).
> In case when authentication and authorization is handled by different security realms in Elytron (i.e. aggregate realm is used) then authorization works only in case, when identity store for realm used for authorization includes the username also for authentication. See Steps to Reproduce for more details.
> We request blocker since using different identity stores for authentication and authorization is common scenario which should be provided by Elytron. Even out documentation explicitly mentioned that scenarios [1]:
> ??Consider the case where users are managed in a central LDAP server and application-specific roles are stored in the application’s relational database.??
> I tried this scenario with Properties and Filesystem Realms for authentication and Properties and Ldap Realms for authorization.
> [1] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (ELY-869) Elytron security realms cannot be used only for authorization
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-869?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reopened ELY-869:
----------------------------
> Elytron security realms cannot be used only for authorization
> -------------------------------------------------------------
>
> Key: ELY-869
> URL: https://issues.jboss.org/browse/ELY-869
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Affects Versions: 1.1.0.Beta18
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: print-roles.war
>
>
> Scenario: I try to configure application server for scenario when different identity stores are used for authentication and authorization (e.g. username/password are stored in LDAP and roles are assigned from Database).
> In case when authentication and authorization is handled by different security realms in Elytron (i.e. aggregate realm is used) then authorization works only in case, when identity store for realm used for authorization includes the username also for authentication. See Steps to Reproduce for more details.
> We request blocker since using different identity stores for authentication and authorization is common scenario which should be provided by Elytron. Even out documentation explicitly mentioned that scenarios [1]:
> ??Consider the case where users are managed in a central LDAP server and application-specific roles are stored in the application’s relational database.??
> I tried this scenario with Properties and Filesystem Realms for authentication and Properties and Ldap Realms for authorization.
> [1] https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-appli...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7864) Missing dependency in wildfly-jms-client-bom
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7864?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7864:
-----------------------------------
Note also that a standalone Java app requires the presence of wildfly-config.xml to negotiate auth with WildFly.
I have updated the helloworld-jms and ejb-remote quickstarts as an example of such configuration (https://github.com/wildfly/quickstart/pull/122)
> Missing dependency in wildfly-jms-client-bom
> --------------------------------------------
>
> Key: WFLY-7864
> URL: https://issues.jboss.org/browse/WFLY-7864
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> I am unable to do JNDI lookup if I use only wildfly-jms-client-bom. I see the following exception
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoadException
> at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:117)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.lambda$static$0(ConfigurationEndpointSupplier.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.<clinit>(ConfigurationEndpointSupplier.java:48)
> at org.wildfly.common.context.ContextManager.setGlobalDefaultSupplierIfNotSet(ContextManager.java:108)
> at org.jboss.remoting3.Endpoint.lambda$static$0(Endpoint.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.Endpoint.<clinit>(Endpoint.java:56)
> at org.wildfly.naming.client.remote.RemoteNamingProviderFactory.supportsUriScheme(RemoteNamingProviderFactory.java:70)
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:318)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.quickstarts.jms.HelloWorldJMSClient.main(HelloWorldJMSClient.java:62)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.modules.ModuleLoadException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {code}
> This issue was marked as Blocker because there shouldn't be needed any additional dependencies if wildfly-jms-client-bom is used.
> *Customer impact:* Standalone clients doesn't work out of the box and programmer has to append additional dependency. This is serious user experience issue. Quickstarts do not work as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-6263) Apostrophe in an attribute with multiple EL parts breaks function lookup
by Daniel Huber (JIRA)
[ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.... ]
Daniel Huber commented on WFLY-6263:
------------------------------------
*push* ... exact same situation here! fix would be appreciated.
> Apostrophe in an attribute with multiple EL parts breaks function lookup
> ------------------------------------------------------------------------
>
> Key: WFLY-6263
> URL: https://issues.jboss.org/browse/WFLY-6263
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Paul Pogonyshev
> Assignee: Jason Greene
> Priority: Critical
> Attachments: jastow-bug.war.zip, jastow.diff
>
>
> Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between.
> This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10.
> Example is attached.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7864) Missing dependency in wildfly-jms-client-bom
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7864?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-7864:
------------------------------
Workaround Description: Add a dependency to org.jboss.modules:jboss-modules in the standalone Java app POM dependencies. (was: Append dependency on jboss-cli-client.jar located in $JBOSS_HOME/bin/client)
> Missing dependency in wildfly-jms-client-bom
> --------------------------------------------
>
> Key: WFLY-7864
> URL: https://issues.jboss.org/browse/WFLY-7864
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> I am unable to do JNDI lookup if I use only wildfly-jms-client-bom. I see the following exception
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoadException
> at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:117)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.lambda$static$0(ConfigurationEndpointSupplier.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.<clinit>(ConfigurationEndpointSupplier.java:48)
> at org.wildfly.common.context.ContextManager.setGlobalDefaultSupplierIfNotSet(ContextManager.java:108)
> at org.jboss.remoting3.Endpoint.lambda$static$0(Endpoint.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.Endpoint.<clinit>(Endpoint.java:56)
> at org.wildfly.naming.client.remote.RemoteNamingProviderFactory.supportsUriScheme(RemoteNamingProviderFactory.java:70)
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:318)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.quickstarts.jms.HelloWorldJMSClient.main(HelloWorldJMSClient.java:62)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.modules.ModuleLoadException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {code}
> This issue was marked as Blocker because there shouldn't be needed any additional dependencies if wildfly-jms-client-bom is used.
> *Customer impact:* Standalone clients doesn't work out of the box and programmer has to append additional dependency. This is serious user experience issue. Quickstarts do not work as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7864) Missing dependency in wildfly-jms-client-bom
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7864?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7864:
-----------------------------------
wildfly-jms-client-bom dependencies are fine.
The actual issue is caused by JBoss Remoting and Elytron that requires JBoss Modules presence while it shouldn't.
Once ELY-872 and REM3-244 are fixed and used by WildFly, there will be no longer this issue in standalone java apps depending on wildfly-jms-client-bom.
> Missing dependency in wildfly-jms-client-bom
> --------------------------------------------
>
> Key: WFLY-7864
> URL: https://issues.jboss.org/browse/WFLY-7864
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> I am unable to do JNDI lookup if I use only wildfly-jms-client-bom. I see the following exception
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoadException
> at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:117)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.lambda$static$0(ConfigurationEndpointSupplier.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.<clinit>(ConfigurationEndpointSupplier.java:48)
> at org.wildfly.common.context.ContextManager.setGlobalDefaultSupplierIfNotSet(ContextManager.java:108)
> at org.jboss.remoting3.Endpoint.lambda$static$0(Endpoint.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.Endpoint.<clinit>(Endpoint.java:56)
> at org.wildfly.naming.client.remote.RemoteNamingProviderFactory.supportsUriScheme(RemoteNamingProviderFactory.java:70)
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:318)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.quickstarts.jms.HelloWorldJMSClient.main(HelloWorldJMSClient.java:62)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.modules.ModuleLoadException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {code}
> This issue was marked as Blocker because there shouldn't be needed any additional dependencies if wildfly-jms-client-bom is used.
> *Customer impact:* Standalone clients doesn't work out of the box and programmer has to append additional dependency. This is serious user experience issue. Quickstarts do not work as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7864) Missing dependency in wildfly-jms-client-bom
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7864?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7864:
-----------------------------------
Elytron should not require the presence of JBoss Modules for client authentication
> Missing dependency in wildfly-jms-client-bom
> --------------------------------------------
>
> Key: WFLY-7864
> URL: https://issues.jboss.org/browse/WFLY-7864
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> I am unable to do JNDI lookup if I use only wildfly-jms-client-bom. I see the following exception
> {code}
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoadException
> at org.jboss.remoting3.EndpointBuilder.build(EndpointBuilder.java:117)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.lambda$static$0(ConfigurationEndpointSupplier.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.ConfigurationEndpointSupplier.<clinit>(ConfigurationEndpointSupplier.java:48)
> at org.wildfly.common.context.ContextManager.setGlobalDefaultSupplierIfNotSet(ContextManager.java:108)
> at org.jboss.remoting3.Endpoint.lambda$static$0(Endpoint.java:58)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.remoting3.Endpoint.<clinit>(Endpoint.java:56)
> at org.wildfly.naming.client.remote.RemoteNamingProviderFactory.supportsUriScheme(RemoteNamingProviderFactory.java:70)
> at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:318)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:123)
> at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:113)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.quickstarts.jms.HelloWorldJMSClient.main(HelloWorldJMSClient.java:62)
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: org.jboss.modules.ModuleLoadException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ... 20 more
> {code}
> This issue was marked as Blocker because there shouldn't be needed any additional dependencies if wildfly-jms-client-bom is used.
> *Customer impact:* Standalone clients doesn't work out of the box and programmer has to append additional dependency. This is serious user experience issue. Quickstarts do not work as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months