[JBoss JIRA] (WFLY-6107) WildFly AccessLog valve migration is not taking the condition parameter into account
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6107?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6107:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> WildFly AccessLog valve migration is not taking the condition parameter into account
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6107
> URL: https://issues.jboss.org/browse/WFLY-6107
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
> Fix For: 11.0.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-7202) generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7202:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-7202
> URL: https://issues.jboss.org/browse/WFLY-7202
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Tom Ross
> Assignee: Tom Ross
> Fix For: 11.0.0.Final
>
>
> The code snippet shows that the method returns wrong type.
> {noformat}
> public String getSessionDefaultType() {
> if (type == JmsConnectionFactory.AGNOSTIC)
> return "agnostic";
> else if (type == JmsConnectionFactory.QUEUE)
> return TOPIC_TYPE;
> else
> return QUEUE_TYPE;
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-3690) Not possible to start XTS transaction on IPv6 with server bound to ::1
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3690?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-3690:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Not possible to start XTS transaction on IPv6 with server bound to ::1
> ----------------------------------------------------------------------
>
> Key: WFLY-3690
> URL: https://issues.jboss.org/browse/WFLY-3690
> Project: WildFly
> Issue Type: Bug
> Components: Transactions, XTS
> Reporter: Stefano Maestri
> Assignee: Amos Feng
> Fix For: 11.0.0.Final
>
>
> Currently we have the following configuration element: <xts-environment url="http://${jboss.bind.address:127.0.0.1}:8080/ws-c11/ActivationService"/>
> If bind address is set to ::1, then xts environment URL becomes http://::1:8080/ws-c11/ActivationService. This is incorrect, because IPv6 address with port number in it suppose to have brackets.
> we could need to split url in 4 different attribute:
> * protocol
> * host
> * port
> * path
> but there isn't a easy way to do the transformer by adding these new attributes. So it's just another solution to split the url and check the address if startsWith ::1, then it needs to add the brackets and join them again.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4260) Schema validation errors against jboss-service_7_0.xsd
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4260?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4260:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Schema validation errors against jboss-service_7_0.xsd
> -------------------------------------------------------
>
> Key: WFLY-4260
> URL: https://issues.jboss.org/browse/WFLY-4260
> Project: WildFly
> Issue Type: Bug
> Reporter: Sande Gilda
> Assignee: Tomas Hofman
> Fix For: 11.0.0.Final
>
>
> When you import a quickstart containing a jboss-service.xml file, you get the following XML:
> cvc-complex-type.2.3: Element 'attribute' cannot have character [children], because the type's content type is element-only.
> The quickstart source is located here:
> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x/hello...
> I searched the https://github.com/jbossas/jboss-eap/ source code for other jboss-service.xml examples, and found a few with syntax similar to what the quickstarts use:
> * sar/src/test/resources/test/serviceXmlDeployment.jar/META-INF/jboss-service.xml
> * testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/sar/injection/jboss-service.xml
> * testsuite/integration/smoke/src/test/java/org/jboss/as/test/smoke/sar/jboss-service.xml
> * arquillian/container-managed/src/test/resources/sar-example.sar/META-INF/jboss-service.xml
> * arquillian/container-remote/src/test/resources/sar-example.sar/META-INF/jboss-service.xml
> There seems to be an error in the schema:
> http://www.jboss.org/schema/jbossas/jboss-service_7_0.xsd
> The quickstart bug is located here: https://bugzilla.redhat.com/show_bug.cgi?id=1178782
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-6155) [Migration][WebToUndertow] RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither migrated and neither migration warning is shown
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6155?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-6155:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> [Migration][WebToUndertow] RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither migrated and neither migration warning is shown
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6155
> URL: https://issues.jboss.org/browse/WFLY-6155
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> When migrating {{RemoteIpValve}} which has defined params {{proxiesHeader}} and {{protocolHeaderHttpsValue}} these params are neither migrated nor migration warning is shown.
> If those params are not migratable, there should be printed at least migration warning for them.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4805) Distributable app causes TransferQueueBundler Invalid argument and Topology errors
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4805?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-4805:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Distributable app causes TransferQueueBundler Invalid argument and Topology errors
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4805
> URL: https://issues.jboss.org/browse/WFLY-4805
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Alpha4
> Environment: Oracle JDK 1.8, Open JDK 1.8, RHEL 7
> Reporter: Michal Karm Babacek
> Assignee: Romain Pelisse
> Labels: rpelisse_wip
> Fix For: 11.0.0.Final
>
> Attachments: clusterbench.war, configs.zip, logs.zip
>
>
> Simple shutdown failover tests are failing due to apparent error in / misconfiguration of the distributed cache.
> If one follows the aforementioned steps to reproduce, the following symptoms appear:
> * Variations on {noformat}SEVERE [org.jgroups.protocols.UDP] (TransferQueueBundler,ee,rhel7gax86-64) JGRP000029: rhel7gax86-64: failed sending message to rhel7gax86-64 (59 bytes): java.io.IOException: Invalid argument, headers: UNICAST3: ACK, seqno=9410, ts=217, UDP: [cluster_name=ee]{noformat}
> * Failures of this kind: {noformat}ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (transport-thread--p2-t12) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 11
> at org.infinispan.statetransfer.StateTransferLockImpl.waitForTransactionData(StateTransferLockImpl.java:92)
> at org.infinispan.interceptors.base.BaseStateTransferInterceptor.waitForTransactionData(BaseStateTransferInterceptor.java:96)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:285)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:254)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:130)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:209)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:97)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:49)
> at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:58)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1617)
> at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:579)
> at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:572)
> at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:442)
> at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:297)
> at org.wildfly.clustering.server.registry.CacheRegistry.topologyChanged(CacheRegistry.java:152)
> at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl$1.run(AbstractListenerImpl.java:286)
> at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
> at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:309)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1180)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1139)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1105)
> at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyTopologyChanged(CacheNotifierImpl.java:560)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:201)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:45)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:113)
> at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:285)
> at org.infinispan.topology.LocalTopologyManagerImpl$1.run(LocalTopologyManagerImpl.java:218)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.runInternal(SemaphoreCompletionService.java:166)
> at org.infinispan.executors.SemaphoreCompletionService$QueueingTask.run(SemaphoreCompletionService.java:144)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){noformat}
> * Warnings such as: {noformat}WARN [org.infinispan.transaction.impl.TransactionTable] (TxCleanupService,dist,rhel7gax86-64) ISPN000326: Remote transaction GlobalTransaction:<rhel7gax86-64>:9373:remote timed out. Rolling back after 70810 ms{noformat}
> Logs from one of such play & test scenarios are attached: [^logs.zip], [^configs.zip].
> Any ideas which configuration directive or application setting might be at the bottom of this?
> Needless to say any such test passes without any error with EAP 6.4 and 6.3 both with shutdown and undeploy failover scenarios.
> Thx for comments.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-7295) Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-7295:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
> Key: WFLY-7295
> URL: https://issues.jboss.org/browse/WFLY-7295
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Zach Rhoads
> Priority: Critical
> Fix For: 11.0.0.Final
>
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> ... 45 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> 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:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 67 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-2129) @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-2129:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2129
> URL: https://issues.jboss.org/browse/WFLY-2129
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Web Services
> Affects Versions: 8.0.0.Alpha4
> Environment: Mac OS X
> Reporter: Nicky Mølholm
> Assignee: Jim Ma
> Fix For: 11.0.0.Final
>
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc)
> A simple EJB with a Web service view can illustrate the first problem:
> {code:java}
> @Stateless
> @WebService
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> @PermitAll // <-- This doesn't work
> //@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> // <--- unless you put them on class level
> public String sayHello(String name) {
> System.out.println("******** Greeter.sayHello(" + name + ")");
> return "Hello " + name;
> }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll,@DenyAll,@RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-8577) Additional privileged blocks for JAXWS client running with Security Manager enabled
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8577?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-8577:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> Additional privileged blocks for JAXWS client running with Security Manager enabled
> -----------------------------------------------------------------------------------
>
> Key: WFLY-8577
> URL: https://issues.jboss.org/browse/WFLY-8577
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Fix For: 11.0.0.Final
>
>
> This is a follow up of CXF-5142 which should enable the JAXWS client to run with Security Manager enabled.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-1526) AS7 JConsole scripts ignore arguments
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-1526?page=com.atlassian.jira.plugin.... ]
Kabir Khan updated WFLY-1526:
-----------------------------
Fix Version/s: 11.0.0.Final
I am bulk closing old issues that were resolved with no fix version. There are quite many of these so I am not checking the history properly. From the lastModified date of this issue it looks like it was done for 11.0.0.Final (I am not caring about alpha/beta etc. for this exercise). If that is incorrect please adjust as needed.
> AS7 JConsole scripts ignore arguments
> --------------------------------------
>
> Key: WFLY-1526
> URL: https://issues.jboss.org/browse/WFLY-1526
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Priority: Minor
> Fix For: 11.0.0.Final
>
>
> JConsole scripts ignore arguments, for instance, sh script:
> jconsole -J-Djava.class.path="$CLASSPATH"
> instead of
> jconsole -J-Djava.class.path="$CLASSPATH" "$@"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months