May 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials

by Pavel Kovalenko (JIRA)

[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ] Pavel Kovalenko commented on WFLY-3221: --------------------------------------- Hi guys. I think it's very critical bug and must be resolved as fast as possible. E.g. in my application I use LDAP and roles changes very often, so I can't reboot server after every change. I was hoping that it will fix in 8.1.0.Final and after I noticed that fix version was changed to 9.0.0.Aplha I was frustrated. I realized that I could not wait any longer and after exploring Wildfly source code I found solution for this problem. Next 2 classes flushes credentials after session destroying. {code:title=CredentialsCatchFilter.java|borderStyle=solid} @WebFilter(urlPatterns = "*") public class CredentialsCatchFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { } public void doFilter(ServletRequest request, ServletResponse response, FilterChain next) throws IOException, ServletException { if (request instanceof HttpServletRequest) { HttpServletRequest httpServletRequest = (HttpServletRequest) request; if (httpServletRequest.getSession().getAttribute("principal") == null && httpServletRequest.getUserPrincipal() != null) { httpServletRequest.getSession().setAttribute("principal", httpServletRequest.getUserPrincipal()); } } next.doFilter(request, response); } @Override public void destroy() { } } {code} {code:title=FlushCredentialsListener.java|borderStyle=solid} @WebListener public class FlushCredentialsListener implements HttpSessionListener { @Resource(name = "java:jboss/jaas/ldap/authenticationMgr") private CacheableManager<?, Principal> authenticationManager; @Override public void sessionCreated(HttpSessionEvent httpSessionEvent) { } @Override public void sessionDestroyed(HttpSessionEvent httpSessionEvent) { Principal principal = (Principal) httpSessionEvent.getSession().getAttribute("principal"); if (principal != null) authenticationManager.flushCache(principal); } } {code} *Note:* In Resource annotation use your security domain name instead of "ldap". Hope, it will help developers to temporarily resolve this problem before official fix. > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 9.0.0.Alpha1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3408) { : } syntax is not explained

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-3408?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on WFLY-3408: ------------------------------------ The syntax is as follows: {code} ${SomeSystemPropertyName:defaultValue} {code} You then set the system property SomeSystemPropertyName (typically) by passing it to the startup script: {code} ./standalone.sh -DSomeSystemPropertyName=foo {code} If it isn't set then the default value which follows the : will be used as the value for the element/attribute which uses that expression. > { : } syntax is not explained > ----------------------------- > > Key: WFLY-3408 > URL: https://issues.jboss.org/browse/WFLY-3408 > Project: WildFly > Issue Type: Documentation > Security Level: Public(Everyone can see) > Components: Documentation > Environment: https://docs.jboss.org/author/display/WFLY8/Admin+Guide#AdminGuide-Interf... > Reporter: Steve Fisher > Assignee: Tom Wells > > The { : } syntax which is used in the provided standalone-full.xml - for example - > <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> > does not appear to be explained. I guess I can set jboss.bind.address.management somewhere to change the default value. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-3418: ---------------------------------- {quote} >we would need to reintroduce the 'old way' for slaves which are backups. correct But the DC should not push deployments (when a user deploys an app) to non-backup HC's which don't need them either. {quote} Yes, that's what I meant. old/aggressive way to backup HCs, new/lazy way to non-backup HCs. Sounds like we agree :-) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne commented on WFLY-3418: ------------------------------------ It's bi-fold really: >we would need to reintroduce the 'old way' for slaves which are backups. correct But the DC should not push deployments (when a user deploys an app) to non-backup HC's which don't need them either. > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-3418: ---------------------------------- Yes, I did not read Dennis's comments properly. It has been a long time since I looked at this code, so the current status might be different. The way we used to have it was that a DC would aggressively push the deployed contents out to all HCs. This was then changed to make the HC lazily fetch the data from the DC once a deployment was pushed to a server group for which it has servers (basically addressing Dennis's concerns). If that is still the case, it sounds like we would need to reintroduce the 'old way' for slaves which are backups. > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Attachment: jboss-module-test.src.zip servlet-cdi-test-jar.src.zip module.multiplejars.zip module.ok.zip servlet-cdi-test3.war servlet-cdi-test3.src.zip > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > Attachments: jboss-module-test.src.zip, module.multiplejars.zip, module.ok.zip, servlet-cdi-test-jar.src.zip, servlet-cdi-test3.src.zip, servlet-cdi-test3.war > > > CDI does not scan module with multiple jars. Only first jar is scanned. > Workaround is to package everything in single jar file. > To reproduce: > {CODE} > #download attached files > #download and unzip wildfly > cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 > unzip ../module.multiplejars.zip > cp ../servlet-cdi-test3.war standalone/deployments/ > ./bin/standalone.sh > # observe deployment fails > # stop server > unzip ../module.ok.zip > ./bin/standalone.sh > # observe deployment succeeds > {CODE} > The same scenario succeeds in both cases on EAP 6.2.x. > module.ok.zip was created from module.multiplejars.zip by merging jar files into single one -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Description: CDI does not scan module with multiple jars. Only first jar is scanned. Workaround is to package everything in single jar file. To reproduce: {CODE} #download attached files #download and unzip wildfly cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 unzip ../module.multiplejars.zip cp ../servlet-cdi-test3.war standalone/deployments/ ./bin/standalone.sh # observe deployment fails # stop server unzip ../module.ok.zip ./bin/standalone.sh # observe deployment succeeds {CODE} The same scenario succeeds in both cases on EAP 6.2.x. module.ok.zip was created from module.multiplejars.zip by merging jar files into single one > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > > CDI does not scan module with multiple jars. Only first jar is scanned. > Workaround is to package everything in single jar file. > To reproduce: > {CODE} > #download attached files > #download and unzip wildfly > cd wildfly-9.0.0.Alpha1-SNAPSHOT #or other version > 8.0.0 > unzip ../module.multiplejars.zip > cp ../servlet-cdi-test3.war standalone/deployments/ > ./bin/standalone.sh > # observe deployment fails > # stop server > unzip ../module.ok.zip > ./bin/standalone.sh > # observe deployment succeeds > {CODE} > The same scenario succeeds in both cases on EAP 6.2.x. > module.ok.zip was created from module.multiplejars.zip by merging jar files into single one -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Affects Version/s: 8.0.0.Final 8.1.0.Final > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3419) beans in module jars are not discovered except the first jar in module

by Petr Sakař (JIRA)

[ https://issues.jboss.org/browse/WFLY-3419?page=com.atlassian.jira.plugin.... ] Petr Sakař updated WFLY-3419: ----------------------------- Component/s: CDI / Weld > beans in module jars are not discovered except the first jar in module > ---------------------------------------------------------------------- > > Key: WFLY-3419 > URL: https://issues.jboss.org/browse/WFLY-3419 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Petr Sakař > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3418) deployed applications are not distributed to host controller(s)

by Tom Fonteyne (JIRA)

[ https://issues.jboss.org/browse/WFLY-3418?page=com.atlassian.jira.plugin.... ] Tom Fonteyne edited comment on WFLY-3418 at 5/30/14 5:33 AM: ------------------------------------------------------------- yes an no. I agree with Denis his comments. Content should only be copied when an HC is started with "\-\-backup" in other words, then the HC is intended to be promoted to DC when needed. HC's without "\-\-backup" should *not* get all application (only the ones its server instances actually need) was (Author: tfonteyn): yes an no. I agree with Denis his comments. Content should only be copied when an HC is started with "--backup" in other words, then the HC is intended to be promoted to DC when needed. HC's without "--backup" should *not* get all application (only the ones its server instances actually need) > deployed applications are not distributed to host controller(s) > --------------------------------------------------------------- > > Key: WFLY-3418 > URL: https://issues.jboss.org/browse/WFLY-3418 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.CR2 > Environment: Wildfly 8.1.0 CR5 domain mode > Reporter: Tom Fonteyne > Assignee: Brian Stansberry > > when a new HC is brought up into an existing DC/HC environment, it does not receive a copy of all deployed applications (e.g. the "content" folder) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 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 May 2014