[JBoss JIRA] (WFLY-7297) It is not possible to explode and browse deployments within deployment
by Jan Stefl (JIRA)
Jan Stefl created WFLY-7297:
-------------------------------
Summary: It is not possible to explode and browse deployments within deployment
Key: WFLY-7297
URL: https://issues.jboss.org/browse/WFLY-7297
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 11.0.0.Alpha1
Reporter: Jan Stefl
Assignee: Claudio Miranda
Attachments: jboss-kitchensink-ear.ear
It is possible to explode and browse content of top level deployment but there is no possibility for such operation with deployment.
Attaching test deployent for experiments.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (ELY-659) Make all mechanism implementations final
by David Lloyd (JIRA)
David Lloyd created ELY-659:
-------------------------------
Summary: Make all mechanism implementations final
Key: ELY-659
URL: https://issues.jboss.org/browse/ELY-659
Project: WildFly Elytron
Issue Type: Task
Components: Authentication Mechanisms, HTTP, SASL
Reporter: David Lloyd
Priority: Critical
Fix For: 1.1.0.Beta11
It is very important to make all the mechanism implementations final. Relatedly, they should have no protected members.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugi... ]
Geoffrey De Smet commented on DROOLS-1323:
------------------------------------------
Experiment that needs to be run: remove DefaultAgenda line 1459: stateMachineLock.notifyAll();
and see if it affects CloudBalancing's speed and profiling.
> DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1323
> URL: https://issues.jboss.org/browse/DROOLS-1323
> Project: Drools
> Issue Type: Task
> Components: core engine
> Reporter: Geoffrey De Smet
> Assignee: Mario Fusco
> Attachments: Selection_240.png, Selection_241.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7296) (7.1.0) When JASPIC's register session is used, Subject not propagated to EJB
by Bartosz Spyrko-Śmietanko (JIRA)
Bartosz Spyrko-Śmietanko created WFLY-7296:
----------------------------------------------
Summary: (7.1.0) When JASPIC's register session is used, Subject not propagated to EJB
Key: WFLY-7296
URL: https://issues.jboss.org/browse/WFLY-7296
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.0.0.Final
Reporter: Bartosz Spyrko-Śmietanko
Assignee: Darran Lofthouse
Fix For: 10.1.0.CR1, 10.1.0.Final
When the JASPIC 1.1 register session ({{javax.servlet.http.registerSession}}) is used, the authenticated identity (via the Subject) is not propagated to the EJB container.
The problems seems to be with {{JASPICAuthenticationMechanism.createAccount}}. When a cached account is re-used, a {{null}} is passed for the {{Subject}} parameter in the call to {{jbossSct.getUtil().createSubjectInfo}}. This will set indeed set a {{SubjectInfo}} with subject being null.
{{EJBContext#getCallerPrincipal}} checks exactly this subject, and when seeing a null will consider the user to be unauthenticated, even when the caller is authenticated in the web layer.
See the code below:
{code:java}
// SAM handled the same principal found in the cached account: indicates we must use the cached account.
if (cachedAccount != null && cachedAccount.getPrincipal() == userPrincipal) {
// populate the security context using the cached account data.
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
null); // PROBLEMATIC NULL
RoleGroup roleGroup = new SimpleRoleGroup(SecurityConstants.ROLES_IDENTIFIER);
for (String role : cachedAccount.getRoles())
roleGroup.addRole(new SimpleRole(role));
jbossSct.getUtil().setRoles(roleGroup);
return cachedAccount;
}
{code}
Instead of passing a {{null}}, passing the existing subject as set by the JASPIC callback handler seems to work:
{code:java}
jbossSct.getUtil().createSubjectInfo(
userPrincipal, ((AccountImpl) cachedAccount).getCredential(),
jbossSct.getUtil().getSubject());
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7280) getSession() Always Creating HttpSession Problem
by kin zhu (JIRA)
[ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.... ]
kin zhu edited comment on WFLY-7280 at 10/12/16 8:17 AM:
---------------------------------------------------------
I'm sorry for the false alarm. Turns out that there're two JSESSIONID cookies and firefox won't merge them. The problem solved right after I cleared the cookies and tried login again.
was (Author: daxiaoming200):
I'm sorry for the false alarm. Turns out that there're two JSESSIONID cookie and firefox won't merge them. The problem solved after I clear the cookies and try login again.
> getSession() Always Creating HttpSession Problem
> -------------------------------------------------
>
> Key: WFLY-7280
> URL: https://issues.jboss.org/browse/WFLY-7280
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: jdk8u102, win7x64, wildfly-servlet-10.1.0.Final.tar.gz
> Reporter: kin zhu
> Assignee: Stuart Douglas
>
> I have a login application called cas.war. I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null. I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request). I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
> {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java, method getSession:{color}
> {code:java}
> public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
> SessionConfig c = originalServletContext.getSessionConfig();
> HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
> {code}
> while
> sessionAttachmentKey = {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
>
> the exchange.attachments map will only contain one such key: {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
> thus the server will create new session once request.getSession() is called, regardless one session exist or not.
> And please have a look at the relate class InMemorySessionManager too.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7280) getSession() Always Creating HttpSession Problem
by kin zhu (JIRA)
[ https://issues.jboss.org/browse/WFLY-7280?page=com.atlassian.jira.plugin.... ]
kin zhu commented on WFLY-7280:
-------------------------------
I'm sorry for the false alarm. Turns out that there're two JSESSIONID cookie and firefox won't merge them. The problem solved after I clear the cookies and try login again.
> getSession() Always Creating HttpSession Problem
> -------------------------------------------------
>
> Key: WFLY-7280
> URL: https://issues.jboss.org/browse/WFLY-7280
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: jdk8u102, win7x64, wildfly-servlet-10.1.0.Final.tar.gz
> Reporter: kin zhu
> Assignee: Stuart Douglas
>
> I have a login application called cas.war. I store the captcha code in session. This application has been running smoothly in JBoss7 and Tomcat7. But when I tried to migrate to wildfly10, I found the captcha code will always be null. I dug a little deeper, and found out that the server is creating new session each time I post a request(the JSESSIONID cookie changes on every request). I traced the code and pinned down the problem on this location (as of undertow-servlet-1.4.0.Final-sources.jar ) :
> {color:#f6c342}io.undertow.servlet.spec.ServletContextImpl.java, method getSession:{color}
> {code:java}
> public HttpSessionImpl getSession(final ServletContextImpl originalServletContext, final HttpServerExchange exchange, boolean create) {
> SessionConfig c = originalServletContext.getSessionConfig();
> HttpSessionImpl httpSession = exchange.getAttachment(sessionAttachmentKey);
> {code}
> while
> sessionAttachmentKey = {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.servlet.spec.HttpSessionImpl>{color}
>
> the exchange.attachments map will only contain one such key: {color:#f6c342}io.undertow.util.SimpleAttachmentKey<io.undertow.server.session.InMemorySessionManager$SessionImpl>{color}
> thus the server will create new session once request.getSession() is called, regardless one session exist or not.
> And please have a look at the relate class InMemorySessionManager too.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (WFLY-7295) Internal server error is returned for Elytron authentication when LDAP server is unreachable
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ]
Ondrej Lukas updated WFLY-7295:
-------------------------------
Affects Version/s: 11.0.0.Alpha1
> Internal server error is returned 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: Darran Lofthouse
> Priority: Critical
>
> 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
(v6.4.11#64026)
8 years, 3 months