March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2648) Review/move the per-logging deployment tests

by Petr Kremensky (JIRA)

[ https://issues.jboss.org/browse/WFLY-2648?page=com.atlassian.jira.plugin.... ] Petr Kremensky reassigned WFLY-2648: ------------------------------------ Assignee: Petr Kremensky (was: James Perkins) > Review/move the per-logging deployment tests > -------------------------------------------- > > Key: WFLY-2648 > URL: https://issues.jboss.org/browse/WFLY-2648 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Reporter: James Perkins > Assignee: Petr Kremensky > Priority: Minor > > The {{org.jboss.as.logging.per-deployment}} property has been deprecated. There are two tests {{LoggingPerDeployFalseTestCase}} and {{LoggingPreferencesPerDeployFalseTestCase}} that use this property. They need to be copied and/or moved to the manualmode tests and modified to use the new attribute. > Also these tests appear not to work correctly. Breaking the system property during the patch, the tests still seemed to pass. They need to be reviewed and tested when working on this issue. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-805) Overload SecurityVaultFactory.get() to be able to specify the classloader

by Kabir Khan (JIRA)

Kabir Khan created SECURITY-805: ----------------------------------- Summary: Overload SecurityVaultFactory.get() to be able to specify the classloader Key: SECURITY-805 URL: https://issues.jboss.org/browse/SECURITY-805 Project: PicketBox Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assignee: Kabir Khan To work better with modular class loading in WF -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3117) Add tests for add-logging-api-dependencies logging attribute

by Petr Kremensky (JIRA)

Petr Kremensky created WFLY-3117: ------------------------------------ Summary: Add tests for add-logging-api-dependencies logging attribute Key: WFLY-3117 URL: https://issues.jboss.org/browse/WFLY-3117 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Petr Kremensky Assignee: Petr Kremensky https://issues.jboss.org/browse/PRODMGT-591 introduced a new logging subsystem attribute add-logging-api-dependencies. Logging dependencies are still added by default. There are already tests in org.jboss.as.test.integration.logging covering default functionality. We have to test the case when logging modules are not available (set value of *add-logging-api-dependencies* to false). *LoggingDependenciesTestCase* * start the server * deploy a archive with dependency on Log4j * verify that deployment was successful and undeploy it * set *add-logging-api-dependencies=false* * reload the server so the changes are propagated * deploy the archive again * exception should be thrown this time during deployment -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2850) AJP connector with external authentication

by Sylvain Brouillat (JIRA)

[ https://issues.jboss.org/browse/WFLY-2850?page=com.atlassian.jira.plugin.... ] Sylvain Brouillat commented on WFLY-2850: ----------------------------------------- Tomcat define tomcatAuthentication attribute for ajp connector, that when set to false, disable tomcatAuthentication and allows apache to handle authentication and pass remote_user throught AJP channel to tomcat (http://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html). I wasn't using AS7/EAP6 but an old configuration AS4, and tomcatAuthentication was set to false by adding ajp connector configuration in server/default/deploy/jbossweb-tomcat55.sar/server.xml : <Connector port="8009" address="${bind.address}" emptySessionPath="true" enableLookup="true" redirectPort="8443" protocol="AJP/1.3" tomcatAuthentication="false" /> It seems to exist a different way to disable tomcatAuthentication in JBoss7.0 (https://issues.jboss.org/browse/WFLY-254). > AJP connector with external authentication > ------------------------------------------ > > Key: WFLY-2850 > URL: https://issues.jboss.org/browse/WFLY-2850 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Reporter: Geert Coelmont > Assignee: Stuart Douglas > Priority: Critical > > Tomcat allows to set the tomcatAuthentication attribute of the AJP connector to false to allow external web servers (e.g. apache httpd) to handle the authentication and pass that along. > A similar option was added recently to JBossWeb as well (see WFLY-254), but JBossWeb has been replaced by Undertow. With Undertow this option isn't available as far as I can see. > For me this is a critical problem as there is currently no way I can do negotiated (SPNEGO) authentication from within WildFly+Undertow. (See also WFLY-2404). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-455. -------------------------------- Fix Version/s: 6.1.0.Beta2 Resolution: Done > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta2 > > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-455: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1076361|https://bugzilla.redhat.com/show_bug.cgi?id=1076361] from NEW to ASSIGNED > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Critical > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-455: ---------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-455) Event expiration calculation may overflow

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-455?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-455: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076361 > Event expiration calculation may overflow > ----------------------------------------- > > Key: DROOLS-455 > URL: https://issues.jboss.org/browse/DROOLS-455 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.6.0.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Critical > > The calculation of the expiration timestamp of an event in the OTN is effectively given by the combination : > {code} > Handle.startTimeStamp + Handle.duration + OTN.expirationOffset > {code} > If the addition overflows, the event will be scheduled for expiration immediately. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3113) Websocket connection fails when connecting to protected URL (basic login)

by Alexandre Nikolov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.... ] Alexandre Nikolov commented on WFLY-3113: ----------------------------------------- After further investigation, I think this is not a problem with WildFly, but a combination of two different issue with: 1. Chrome connecting to protected endpoint 2. Atmosphere when the incoming connection is to protected endpoint. With unprotected endpoint everything works as expected. So I am changing this issue type to "Clarification". Probably someone needs to take this with Chrome dev. team. > Websocket connection fails when connecting to protected URL (basic login) > ------------------------------------------------------------------------- > > Key: WFLY-3113 > URL: https://issues.jboss.org/browse/WFLY-3113 > Project: WildFly > Issue Type: Clarification > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux > Chrome, Firefox > Reporter: Alexandre Nikolov > Assignee: Stuart Douglas > Labels: jsr356,, login > > In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in. > When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers: > 1. Chrome fails with 401 error code and the log-in screen is not displayed at all. > 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds. > But in a different application, using Atmosphere - both connections fails: > 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling > 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it. > For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) > Here is the related discussion on the Atmosphere users group: > https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc > There is test WAR and source in the Atmosphere forum to reproduce the problem. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3113) Websocket connection fails when connecting to protected URL (basic login)

by Alexandre Nikolov (JIRA)

[ https://issues.jboss.org/browse/WFLY-3113?page=com.atlassian.jira.plugin.... ] Alexandre Nikolov updated WFLY-3113: ------------------------------------ Description: In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in. When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers: 1. Chrome fails with 401 error code and the log-in screen is not displayed at all. 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds. But in a different application, using Atmosphere - both connections fails: 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it. For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info) Here is the related discussion on the Atmosphere users group: https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc There is test WAR and source in the Atmosphere forum to reproduce the problem. was: In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in. When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers: 1. Chrome fails with 401 error code and the log-in screen is not displayed at all. 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds. But in a different application, using Atmosphere - both connections fails: 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it. For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request wuld be the path info) Here is the related discussion on the Atmosphere users group: https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc There is test WAR and source in the Atmosphere forum to reproduce the problem. > Websocket connection fails when connecting to protected URL (basic login) > ------------------------------------------------------------------------- > > Key: WFLY-3113 > URL: https://issues.jboss.org/browse/WFLY-3113 > Project: WildFly > Issue Type: Clarification > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.Final > Environment: WildFly 8.0.0.Final, Windows 8, RedHat Linux > Chrome, Firefox > Reporter: Alexandre Nikolov > Assignee: Stuart Douglas > Labels: jsr356,, login > > In a sample application for JSR356 support, added security constraints with basic log-in. The websocket endpoint is protect with basic log-in. > When a websocket connection is attempted to the protected URL, there is inconsistent behavior in different browsers: > 1. Chrome fails with 401 error code and the log-in screen is not displayed at all. > 2. Firefox displays the log-in screen and the websocket is created and opened after the log-in succeeds. > But in a different application, using Atmosphere - both connections fails: > 1. Chrome fails with the same error and the log-in screen is displayed after that. Most probably the log-in screen is triggered by Atmosphere when it falls back to long-polling > 2. Firefox - The login screen is displayed and if the log-in suceeds, the socket is created, but Atmosphere fails to process it. > For example if the context root is "jsr356test" and the protected path is /pubsub/protected, Atmosphere tries to map /jsr356test/pubsub/protected (which in JSR356 is Session#getRequestURI()) but has mapping set-up for /pubsub/protected (which for a Http request would be the path info) > Here is the related discussion on the Atmosphere users group: > https://groups.google.com/forum/#!topic/atmosphere-framework/ntIHOohlYIc > There is test WAR and source in the Atmosphere forum to reproduce the problem. -- 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, 4 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 March 2014