February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation

by Stan Silvert (JIRA)

[ https://issues.jboss.org/browse/WFLY-2981?page=com.atlassian.jira.plugin.... ] Stan Silvert commented on WFLY-2981: ------------------------------------ I understand that we need a readable date for CLI, but we also need another attribute that reports this date as a long. Otherwise, it is difficult to display and sort the list in a GUI. > Add a date format attribute to the list-log-files operation > ----------------------------------------------------------- > > Key: WFLY-2981 > URL: https://issues.jboss.org/browse/WFLY-2981 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1067612|https://bugzilla.redhat.com/show_bug.cgi?id=1067612] from NEW to POST > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-797: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1067610, https://bugzilla.redhat.com/show_bug.cgi?id=1067612 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1067610) > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-797: -------------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1067610|https://bugzilla.redhat.com/show_bug.cgi?id=1067610] from NEW to POST > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-797) Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-797?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-797: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1067610 > Authentication attempts will fail if the DatabaseRolesMappingProvider's rolesQuery returns an empty set > ------------------------------------------------------------------------------------------------------- > > Key: SECURITY-797 > URL: https://issues.jboss.org/browse/SECURITY-797 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JBossSX > Affects Versions: PicketBox_4_0_19.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-797.patch > > > If the DatabaseRolesMappingProvider's rolesQuery returns an empty set, then the authentication attempts will fail. Seems like it should not cause the authentication attempt to fail, since this is about mapping/adding roles. > It looks like the code detects that the result set is empty, but then it tries to get the role from the empty set. This causes an exception which in turn causes the authentication attempt to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2981) Add a date format attribute to the list-log-files operation

by James Perkins (JIRA)

James Perkins created WFLY-2981: ----------------------------------- Summary: Add a date format attribute to the list-log-files operation Key: WFLY-2981 URL: https://issues.jboss.org/browse/WFLY-2981 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Logging Reporter: James Perkins Assignee: James Perkins Priority: Minor The {{list-log-files}} operation outputs the last modified date of the available log files. The current date format is {{yyyy-MM-dd'T'HH:mm:ss.SSSZ}}, but it could be useful for the operation to allow any valid {{SimpleDateFormat}} to be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2962) NPE during deployment of an exploded war, containing jar with resources

by Ercan Oezkan (JIRA)

[ https://issues.jboss.org/browse/WFLY-2962?page=com.atlassian.jira.plugin.... ] Ercan Oezkan commented on WFLY-2962: ------------------------------------ Duplicate, see UNDERTOW-190 > NPE during deployment of an exploded war, containing jar with resources > ----------------------------------------------------------------------- > > Key: WFLY-2962 > URL: https://issues.jboss.org/browse/WFLY-2962 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final, 8.0.1.Final > Reporter: Alexander Nikitin > Assignee: Stuart Douglas > > How to repeat: > Scratch maven Web Application with dependency, f.e. org.primefaces:primefaces > goes into: > {noformat} > 12:28:10,624 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-3) Critical error during deployment: : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: java.lang.NullPointerException > at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:751) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:349) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:214) [jsf-impl-2.2.5-jbossorg-3.jar:] > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:187) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:86) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:71) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0] > Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException > at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.8.0] > at java.util.concurrent.FutureTask.get(FutureTask.java:192) [rt.jar:1.8.0] > at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:738) [jsf-impl-2.2.5-jbossorg-3.jar:] > ... 11 more > Caused by: java.lang.NullPointerException > at io.undertow.servlet.spec.ServletContextImpl.getResourcePaths(ServletContextImpl.java:206) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] > at com.sun.faces.config.configprovider.WebAppFlowConfigResourceProvider.getResources(WebAppFlowConfigResourceProvider.java:79) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.config.ConfigManager$URITask.call(ConfigManager.java:1306) [jsf-impl-2.2.5-jbossorg-3.jar:] > at com.sun.faces.config.ConfigManager$URITask.call(ConfigManager.java:1275) [jsf-impl-2.2.5-jbossorg-3.jar:] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0] > at com.sun.faces.config.ConfigManager.getConfigDocuments(ConfigManager.java:729) [jsf-impl-2.2.5-jbossorg-3.jar:] > ... 11 more > {noformat} > during exploded deployment. > which is caused by > {noformat} > org.wildfly.extension.undertow.deployment.VirtualFileResource.getResourceManagerRoot() > {noformat} > always returning null > which is dereferenced by > {noformat} > io.undertow.servlet.spec.ServletContextImpl.getResourcePaths(final String path) > {noformat} > Patching > VirtualFileResource.getResourceManagerRoot() > as > return new File(""); > works for me, but i'm not sure about getResourceManagerRoot() contract saying that it may actually return null if the resource does not map to a file. > From my point of view Resource interface should have stronger contract concerning nulls -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-796: -------------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1065486|https://bugzilla.redhat.com/show_bug.cgi?id=1065486] from NEW to POST > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-796) LdapExtended login module does not handle a user that has a slash character in the uid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-796?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-796: -------------------------------------------------- Derek Horton <dehort(a)redhat.com> changed the Status of [bug 1067599|https://bugzilla.redhat.com/show_bug.cgi?id=1067599] from NEW to POST > LdapExtended login module does not handle a user that has a slash character in the uid > -------------------------------------------------------------------------------------- > > Key: SECURITY-796 > URL: https://issues.jboss.org/browse/SECURITY-796 > Project: PicketBox > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Derek Horton > Assignee: Stefan Guilhen > Attachments: SECURITY-796.patch > > > LdapExtended login module does not handle a user that has a slash character in the uid. > For example, JBoss will fail to authenticate the following user correctly: > dn: uid=weird/user,ou=Users,dc=my-domain,dc=com > uid: weird/user > cn: Weird User -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2970) CLI doesn't return actual runtime configuration

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2970?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2970. ------------------------------- Fix Version/s: JBoss AS7 7.2.0.Final Resolution: Out of Date Reopen if you find this issue any more recent version. WildFly 8 preferable... > CLI doesn't return actual runtime configuration > ----------------------------------------------- > > Key: WFLY-2970 > URL: https://issues.jboss.org/browse/WFLY-2970 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Debbie Steigner > Assignee: Alexey Loubyansky > Fix For: JBoss AS7 7.2.0.Final > > > If you start your server with -u commandline argument to bind your jgroups-udp to another IP (i.e. 230.0.0.13), the boot.log shows jboss.default.multicast.address = 230.0.0.13 > but if you read the resource via jboss-cli it shows just the default that is set in the standalone-ha.xml. Is there a way to get the actual value via jboss-cli? or is this a bug? > [standalone@127.0.0.1:9999 /] /socket-binding-group=standard-sockets/socket-binding=jgroups-udp:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", > "multicast-port" => 45688, > "name" => "jgroups-udp", > "port" => 55200 > } > } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 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 February 2014