[JBoss JIRA] (WFLY-3226) Add test cases to verify LDAP caching on security realms.
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3226?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-3226:
------------------------------------
Hi Darran,
have you any experience writnig interceptors for apache ds. Following the tutorial https://cwiki.apache.org/confluence/display/DIRxSRVx11/6.2.+Implementing+..., writing just some message to output, test LdapAuthenticationSuiteTest have been broken. Test was unable to login sucesfully. Is there any interceptor already in project I can look into?
Thanx
> Add test cases to verify LDAP caching on security realms.
> ---------------------------------------------------------
>
> Key: WFLY-3226
> URL: https://issues.jboss.org/browse/WFLY-3226
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management, Test Suite
> Reporter: Darran Lofthouse
> Fix For: Awaiting Volunteers
>
>
> The existing test cases are based on a statically defined set of LDIFs, testing of caching could consider a couple of options: -
> 1 - Interceptors within ApacheDS to verify if calls hit the directory.
> 2 - Updates to the directory that would affect the outcome of tests if there is a cache hit, tests can then be repeated with and without clearing the cache.
> Note: It would be beneficial for this to use different users and groups and maybe even different partitions so that test ordering does not affect the outcome if changes are made to the directory.
--
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, 2 months
[JBoss JIRA] (DROOLS-296) Drools date coercion and conditional OR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-296?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-296:
------------------------------------------------
Edson Tirelli <etirelli(a)redhat.com> changed the Status of [bug 1072217|https://bugzilla.redhat.com/show_bug.cgi?id=1072217] from NEW to ASSIGNED
> Drools date coercion and conditional OR
> ---------------------------------------
>
> Key: DROOLS-296
> URL: https://issues.jboss.org/browse/DROOLS-296
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 7
> Reporter: Madhura Jayaratne
> Assignee: Mario Fusco
> Fix For: 6.0.1.Final
>
>
> If I try a simple Drools rule with conditions on date type and uses conditional OR (||) I get the following error. If I change || to && it works fine.
> Condition
> $container: DateContainer( date >= "15-Oct-2013" || date <= "01-Oct-2013" )
> Error
> Unable to Analyse Expression date >= "15-Oct-2013" || date <= "01-Oct-2013":
> [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]
> [Near : {... date >= "15-Oct-2013" || date <= "01-Oct-2013" ....}]
> ^
> [Line: 9, Column: 1] : [Rule name='Test rule']
--
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, 2 months
[JBoss JIRA] (WFLY-675) Link to Console missing from Welcome page
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-675?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-675.
-----------------------------------
Fix Version/s: (was: Awaiting Volunteers)
Resolution: Won't Fix
The existing behavior is deliberate and I don't foresee us changing it, so I'm resolving this as Won't Fix.
> Link to Console missing from Welcome page
> -----------------------------------------
>
> Key: WFLY-675
> URL: https://issues.jboss.org/browse/WFLY-675
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Chuck Mosher
> Labels: eap6-ux
> Attachments: ConsoleWithLinkScreenshot.png, ConsoleWithoutLinkScreenshot.png
>
>
> If I start up the app server(s) using "bin/domain.sh", I can open up the starting page @ localhost:8080/ but there is no link to open the console; only to examine the documentation. The link to the Console is there when running standalone.sh. See attached screenshots.
> Options are: leave the link in there, but when clicked it will result in an error message instructing the user they need to pick which instance they want to examine. Or, point it to localhost:9990/.
--
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, 2 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3279?page=com.atlassian.jira.plugin.... ]
Mehboob Alam updated WFLY-3279:
-------------------------------
Description:
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
This behavior also appears to be different than that of java.net.URL,
public URL(URL context, String spec)
throws MalformedURLException
which states this: If the spec's path component begins with a slash character "/" then the path is treated as absolute and the spec path replaces the context path.
Otherwise, the path is treated as a relative path and is appended to the context path, as described in RFC2396. Also, in this case, the path is canonicalized through the removal of directory changes made by occurences of ".." and ".".
was:
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
> HttpServletResponse.sendRedirect() not working for relative URL
> ---------------------------------------------------------------
>
> Key: WFLY-3279
> URL: https://issues.jboss.org/browse/WFLY-3279
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Windows
> Reporter: Mehboob Alam
> Assignee: Stuart Douglas
> Attachments: Recreate_SendRedirect_Problem.ear
>
>
> I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
>
> The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
> To test this, I enter my app's URL like this-
> http://localhost:8080/helloworld/hello
> Then, inside the first servlet, I do a redirect -
> String url = "../goodbye/bye";
> response.sendRedirect(response.encodeRedirectURL(url));
> wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
> http://localhost:8080/goodbye/bye
> JBoss eap-6-1-0
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 200 localhost:8080 /goodbye/bye/
> WildFly 8.0 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 404 localhost:8080 /helloworld/
> WildFly 8.1.0 CR1 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 403 localhost:8080 /helloworld/
> This behavior also appears to be different than that of java.net.URL,
> public URL(URL context, String spec)
> throws MalformedURLException
> which states this: If the spec's path component begins with a slash character "/" then the path is treated as absolute and the spec path replaces the context path.
> Otherwise, the path is treated as a relative path and is appended to the context path, as described in RFC2396. Also, in this case, the path is canonicalized through the removal of directory changes made by occurences of ".." and ".".
--
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, 2 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
Mehboob Alam created WFLY-3279:
----------------------------------
Summary: HttpServletResponse.sendRedirect() not working for relative URL
Key: WFLY-3279
URL: https://issues.jboss.org/browse/WFLY-3279
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.1.0.CR1, 8.0.0.Final
Environment: Windows
Reporter: Mehboob Alam
Assignee: Stuart Douglas
Attachments: Recreate_SendRedirect_Problem.ear
I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
To test this, I enter my app's URL like this-
http://localhost:8080/helloworld/hello
Then, inside the first servlet, I do a redirect -
String url = "../goodbye/bye";
response.sendRedirect(response.encodeRedirectURL(url));
wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
http://localhost:8080/goodbye/bye
JBoss eap-6-1-0
Status Host Path
302 localhost:8080 /helloworld/hello
200 localhost:8080 /goodbye/bye/
WildFly 8.0 Final
Status Host Path
302 localhost:8080 /helloworld/hello
404 localhost:8080 /helloworld/
WildFly 8.1.0 CR1 Final
Status Host Path
302 localhost:8080 /helloworld/hello
403 localhost:8080 /helloworld/
--
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, 2 months
[JBoss JIRA] (WFLY-3279) HttpServletResponse.sendRedirect() not working for relative URL
by Mehboob Alam (JIRA)
[ https://issues.jboss.org/browse/WFLY-3279?page=com.atlassian.jira.plugin.... ]
Mehboob Alam updated WFLY-3279:
-------------------------------
Attachment: Recreate_SendRedirect_Problem.ear
> HttpServletResponse.sendRedirect() not working for relative URL
> ---------------------------------------------------------------
>
> Key: WFLY-3279
> URL: https://issues.jboss.org/browse/WFLY-3279
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Windows
> Reporter: Mehboob Alam
> Assignee: Stuart Douglas
> Attachments: Recreate_SendRedirect_Problem.ear
>
>
> I cannot get HttpServletResponse.sendRedirect() to work correctly. This only happens to me with Wildfly. It works on previous versions of JBoss EAP/AS and several other app servers where I tested the scenario.
>
> The sample app has two servlet. I navigate from one to the other using sendRedirect. The key seems to be relative path in the form "../whatever/whatever" is not working.
> To test this, I enter my app's URL like this-
> http://localhost:8080/helloworld/hello
> Then, inside the first servlet, I do a redirect -
> String url = "../goodbye/bye";
> response.sendRedirect(response.encodeRedirectURL(url));
> wildfly 8 gives me a HTTP Status 404. wildfly 8.1 CR1 gives me a HTTP Status 403. All other app server works. It takes me to this url:
> http://localhost:8080/goodbye/bye
> JBoss eap-6-1-0
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 200 localhost:8080 /goodbye/bye/
> WildFly 8.0 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 404 localhost:8080 /helloworld/
> WildFly 8.1.0 CR1 Final
> Status Host Path
> 302 localhost:8080 /helloworld/hello
> 403 localhost:8080 /helloworld/
--
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, 2 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by Remy Maucherat (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
Remy Maucherat commented on JBWEB-297:
--------------------------------------
Ok, thanks for the testing. Normally, only the call to event really needs to be synced, I'll leave process out of it.
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
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, 2 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn commented on JBWEB-297:
------------------------------------
Yeah, looks like it is not reproduced any longer with NioEndpoint.ChannelProcessor.run() synced as exampled in JBWEB-297.diff. Thanks, Remy.
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
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, 2 months
[JBoss JIRA] (JBWEB-297) NIO can improperly lead to request/response objects being used concurrently
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/JBWEB-297?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn updated JBWEB-297:
-------------------------------
Attachment: JBWEB-297.diff
> NIO can improperly lead to request/response objects being used concurrently
> ---------------------------------------------------------------------------
>
> Key: JBWEB-297
> URL: https://issues.jboss.org/browse/JBWEB-297
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat
> Affects Versions: JBossWeb-7.2.2.GA, JBossWeb-7.3.0.GA, JBossWeb-7.4.0.GA
> Reporter: Aaron Ogburn
> Assignee: Remy Maucherat
> Attachments: JBWEB-297.diff
>
>
> Using NIO with async servlets can improperly lead to a processor and its request/response objects being used by multiple threads to process different requests at once. The problem arises here in Http11NioProtocol.event():
> {code:title=Http11NioProtocol.java|borderStyle=solid}
> public SocketState event(NioChannel channel, SocketStatus status) {
> Http11NioProcessor processor = connections.get(channel.getId());
> SocketState state = SocketState.CLOSED;
> if (processor != null) {
> processor.startProcessing();
> // Call the appropriate event
> try {
> state = processor.event(status);
> } catch (java.net.SocketException e) {
> // SocketExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> } catch (java.io.IOException e) {
> // IOExceptions are normal
> CoyoteLogger.HTTP_NIO_LOGGER.socketException(e);
> }
> // Future developers: if you discover any other
> // rare-but-nonfatal exceptions, catch them here, and log as
> // above.
> catch (Throwable e) {
> // any other exception or error is odd. Here we log it
> // with "ERROR" level, so it will show up even on
> // less-than-verbose logs.
> CoyoteLogger.HTTP_NIO_LOGGER.socketError(e);
> } finally {
> if (state != SocketState.LONG) {
> connections.remove(channel.getId());
> recycledProcessors.offer(processor);
> {code}
> If two events occur on the same channel and execute this at the same time, it'll lead to this issue if they result in a SocketState other than LONG. When that happens, they both offer the same processor to recycledProcessors in the finally block. Later on, two different requests can then poll the same processor at once from reycledProcessors; a processor should only ever have one entry in recycledProcessors.
> It looks like we need to synch the Http11NioProtocol.event() call or the NioEndpoint.ChannelProcessor.run().
--
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, 2 months