[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
10 years, 10 months
[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
10 years, 10 months
[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
10 years, 10 months
[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:
------------------------------------
Issue Type: Clarification (was: Bug)
> 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
10 years, 10 months
[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 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.
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 because the reques.getPathInfo() returns the context root prepended to the path info.
For example if the context root is "jsr356test" and the protected path is /pubsub/protected, the path info returned is /jsr356test/pubsub/protected instead of /pubsub/protected
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: Bug
> 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
10 years, 10 months
[JBoss JIRA] (WFLY-2493) EL cannot access public methods/fields of non-public classes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2493?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2493:
-----------------------------------------------
Jimmy Wilson <jawilson(a)redhat.com> changed the Status of [bug 1076320|https://bugzilla.redhat.com/show_bug.cgi?id=1076320] from NEW to POST
> EL cannot access public methods/fields of non-public classes
> ------------------------------------------------------------
>
> Key: WFLY-2493
> URL: https://issues.jboss.org/browse/WFLY-2493
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Environment: JBoss AS 7.2.0.Final
> Reporter: Jonáš Trantina
> Attachments: elresolver_stack, reproducer.zip
>
>
> When trying to access public method/field of non-public class that implements public interface via EL I get
> {noformat}
> java.lang.IllegalAccessException: Class javax.el.BeanELResolver can not access a member of class X with modifiers "private"
> {noformat}
> E.g. accessing Collections.unmodifiableList(..).size() via EL will throw the exception, because #unmodifiableList returns non-public implementation of List interface.
> This is apparently caused by JDK-4071957 [1], but since that is opened for over 16 years, it should be probably worth it to implement a workaround.
> Workaround for this issue is setting setAccessible(true) on the method before invoking it, thus suppress Java access checking.
> I have attached a simple reproducer app as well as a stack trace of the exception.
> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
--
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
10 years, 10 months