[JBoss JIRA] (ARQ-1413) Warp: The request is processed even though the transfer of inspection failed
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1413?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1413:
---------------------------------
As we have addressed fix of reporting, I don't see any presure to make the proxy fail the request.
Scheduling to {{.next}}
> Warp: The request is processed even though the transfer of inspection failed
> ----------------------------------------------------------------------------
>
> Key: ARQ-1413
> URL: https://issues.jboss.org/browse/ARQ-1413
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Aslak Knutsen
>
> Originally reported in ARQ-1400.
> Lukas:
> {quote}
> When the inspection is wrapped to a payload ({{RequestPayload}} / {{ResponsePayload}}) and tried to be serialized, it can fail.
> In this case, the response should contain failure to indicate that something went wrong in the request processing.
> {quote}
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-1410) Remove the log4j.properties from Warp
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1410?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1410:
----------------------------
Description:
Upgrade to LittleProxy brought dependency on Log4j.
When no log4j properties is found, then Log4j (LittleProxy) logs excesively.
Find a way how to get rid of the log4j properties file on the classpath.
was:
Upgrade to LittleProxy brought dependency on Log4j.
When no log4j properties is found, then Log4j (LittleProxy) logs excesively.
> Remove the log4j.properties from Warp
> -------------------------------------
>
> Key: ARQ-1410
> URL: https://issues.jboss.org/browse/ARQ-1410
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Reporter: Lukáš Fryč
>
> Upgrade to LittleProxy brought dependency on Log4j.
> When no log4j properties is found, then Log4j (LittleProxy) logs excesively.
> Find a way how to get rid of the log4j properties file on the classpath.
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-1366) Warp: support server-side testing of web pages that require authentication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1366?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1366:
---------------------------------
Let's make this target for upcoming releases as it seems it comes out of scope of {{1.0.0.Final}}.
I would like to see it implemented. So I would appreciate any help with making this happen.
----
I think it comes to setting up little example followed by tests which will serve as reference usage.
> Warp: support server-side testing of web pages that require authentication
> --------------------------------------------------------------------------
>
> Key: ARQ-1366
> URL: https://issues.jboss.org/browse/ARQ-1366
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Oliver Bock
> Assignee: Oliver Bock
> Labels: authentication, exception, warp
> Fix For: warp_1.next
>
>
> When web pages are protected by a security-constraint (web.xml) that requires authentication, Warp JSF runs into a {{SynchronizationPoint$ServerResponseTimeoutException}} while executing server-side tests using {{inspect()}}, like the second one below. Standard FORM authentication (via {{j_security_check}}) and Web Driver's {{htmlunit}} browser are used in this case.
> More observations:
> * Client-side tests work just fine (first test below)
> * Disabling the security-constraint (no authentication) allows the server-side test to finish successfully
> {noformat}
> @Test
> @RunAsClient
> public void testOnClient() {
> browser.get(deploymentUrl + "index.xhtml");
> doLoginIfNeeded(browser);
> // this works just fine!
> Assert.assertEquals("INDEX", browser.getTitle());
> }
> @Test
> @RunAsClient
> public void testOnServer() {
> Warp.initiate(new Activity() {
> @Override
> public void perform() {
> browser.get(deploymentUrl + "index.xhtml");
> doLoginIfNeeded(browser);
> // this works just fine!
> Assert.assertEquals("INDEX", browser.getTitle());
> }
> })
> .group()
> .observe(request().uri().contains("index.xhtml"))
> .inspect(new Inspection() {
> private static final long serialVersionUID = 1L;
> @ArquillianResource
> private FacesContext facesContext;
> @AfterPhase(RENDER_RESPONSE)
> @SuppressWarnings("unused")
> public void testNavigation() {
> // timeout exception before we reach this
> Assert.assertTrue(facesContext.getViewRoot().getViewId().contains("index.xhtml"));
> }
> })
> .execute();
> }
> {noformat}
> Note: {{doLoginIfNeeded()}} is just a helper method that enters user name and password and hits the login button if the login form popped-up (in case there's no active session) following the initial {{browser.get()}} request in the test.
> Exception:
> {noformat}
> org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint$ServerResponseTimeoutException
> at org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses(SynchronizationPoint.java:155)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultExecutionSynchronizer.waitForResponse(DefaultExecutionSynchronizer.java:60)
> at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.awaitResponse(WarpExecutionObserver.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.awaitServerExecution(DefaultWarpExecutor.java:95)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.execute(DefaultWarpExecutor.java:65)
> at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.executeWarp(WarpExecutionObserver.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> {noformat}
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-1366) Warp: support server-side testing of web pages that require authentication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1366?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1366:
----------------------------
Fix Version/s: warp_1.next
> Warp: support server-side testing of web pages that require authentication
> --------------------------------------------------------------------------
>
> Key: ARQ-1366
> URL: https://issues.jboss.org/browse/ARQ-1366
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Oliver Bock
> Assignee: Oliver Bock
> Labels: authentication, exception, warp
> Fix For: warp_1.next
>
>
> When web pages are protected by a security-constraint (web.xml) that requires authentication, Warp JSF runs into a {{SynchronizationPoint$ServerResponseTimeoutException}} while executing server-side tests using {{inspect()}}, like the second one below. Standard FORM authentication (via {{j_security_check}}) and Web Driver's {{htmlunit}} browser are used in this case.
> More observations:
> * Client-side tests work just fine (first test below)
> * Disabling the security-constraint (no authentication) allows the server-side test to finish successfully
> {noformat}
> @Test
> @RunAsClient
> public void testOnClient() {
> browser.get(deploymentUrl + "index.xhtml");
> doLoginIfNeeded(browser);
> // this works just fine!
> Assert.assertEquals("INDEX", browser.getTitle());
> }
> @Test
> @RunAsClient
> public void testOnServer() {
> Warp.initiate(new Activity() {
> @Override
> public void perform() {
> browser.get(deploymentUrl + "index.xhtml");
> doLoginIfNeeded(browser);
> // this works just fine!
> Assert.assertEquals("INDEX", browser.getTitle());
> }
> })
> .group()
> .observe(request().uri().contains("index.xhtml"))
> .inspect(new Inspection() {
> private static final long serialVersionUID = 1L;
> @ArquillianResource
> private FacesContext facesContext;
> @AfterPhase(RENDER_RESPONSE)
> @SuppressWarnings("unused")
> public void testNavigation() {
> // timeout exception before we reach this
> Assert.assertTrue(facesContext.getViewRoot().getViewId().contains("index.xhtml"));
> }
> })
> .execute();
> }
> {noformat}
> Note: {{doLoginIfNeeded()}} is just a helper method that enters user name and password and hits the login button if the login form popped-up (in case there's no active session) following the initial {{browser.get()}} request in the test.
> Exception:
> {noformat}
> org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint$ServerResponseTimeoutException
> at org.jboss.arquillian.warp.impl.client.execution.SynchronizationPoint.awaitResponses(SynchronizationPoint.java:155)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultExecutionSynchronizer.waitForResponse(DefaultExecutionSynchronizer.java:60)
> at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.awaitResponse(WarpExecutionObserver.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.awaitServerExecution(DefaultWarpExecutor.java:95)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultWarpExecutor.execute(DefaultWarpExecutor.java:65)
> at org.jboss.arquillian.warp.impl.client.execution.WarpExecutionObserver.executeWarp(WarpExecutionObserver.java:45)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> {noformat}
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1370:
---------------------------------
Hey Oliver, I agree that Warp should be able to work with SSL.
{quote}
Well, as described earlier, it does - at least for client-side tests in a test class annotated with @WarpTest. That's why this issue seemed like a Alpha2->Alpha3 regression from a user's (my) perspective: for some reason Warp-enriched client-side tests do fail with Alpha3 while they work with Alpha2 (via SSL).
{quote}
The thing is that Warp needs to be able to intercept the request flowing through proxy from client to server - it basically needs to know request/response headers (in order to be able select particular request which should be intercepted).
I'm not sure whether LittleProxy current supports SSL handshake - it seems so, however as I said, we are not interested just in transporation level (HTTP-over-SSL), but rather in presentation layer (details of HTTP request).
It seems that LittleProxy team recently added support for SSL interception (Man in the Middle - MITM) [1] to 0.6.0-SNAPSHOT (Warp currently uses 0.5.3).
{quote}
I guess the major difference compared to Alpha2 is the additional request in Alpha3 you describe: while Alpha2 (enriched) client-side tests, issuing requests via Drone/WebDriver, simply run in JBoss's configured SSL context, Alpha3 (enriched) client-side tests involve CommandService creating a new request itself, somehow outside the container's SSL context...? If my assessment is correct the question should be, can you tap into the container's SSL context or adopt it somehow? If not, you most likely need to establish your own, as suggested by your proposed workaround, if Warp's architecture itself can't be changed/improved in that regard.
{quote}
That's interesting, what have happened in Alpha2:
{code}
client --HTTPS--> proxy --HTTPS with payload--> server
{code}
* on the proxy, we had to have access to HTTP headers
* in order to add additional request header (which contains payload)
How it works in Alpha3:
{code}
client --HTTPS--> proxy --HTTPS with flag--> server
proxy --CommandService--> server
{code}
* we still need to have access to request headers (adding a flag (serialId of the message)
* but proxy needs to be able to connect independently to server
You are talking about SSL contexts, but I think it actually stands for SSL certificates setup for {{client}} (browser?) and {{proxy}} (test JVM) and in Alpha3, the {{test}} itself (CommandService, test JVM).
Any chance you could look at this issue more closely? I can provide you with guidance.
[1] https://github.com/adamfisk/LittleProxy/commit/8cb5b470ad3368badc15d6da67...
> Warp: support SSL for CommandService using untrusted communication
> ------------------------------------------------------------------
>
> Key: ARQ-1370
> URL: https://issues.jboss.org/browse/ARQ-1370
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha3
> Reporter: Lukáš Fryč
>
> We can make use of HTTP client which will automatically trust SSL endpoint.
> http://stackoverflow.com/questions/2703161/how-to-ignore-ssl-certificate-...
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-856) Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
by sarah333 Aldhen (JIRA)
[ https://issues.jboss.org/browse/ARQ-856?page=com.atlassian.jira.plugin.sy... ]
sarah333 Aldhen commented on ARQ-856:
-------------------------------------
I changed the version from 1.0.0.CR2 to CR4 and the exception disappeared but still have other problem :) Thank you Vineet Reynolds
> Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-856
> URL: https://issues.jboss.org/browse/ARQ-856
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: glassfish_1.0.0.CR4
>
>
> The embedded GlassFish container uses the default HTTP bind port of 8181, even though the user-supplied domain configuration XML file may specify a different HTTP port. This results in the following exception being thrown when the Arquillian client attempts to execute a test:
> {code}
> ...
> INFO: WELD-000900 SNAPSHOT
> 9 Apr, 2012 11:06:12 AM com.sun.enterprise.web.WebApplication start
> INFO: WEB0671: Loading application [test] at [/test]
> 9 Apr, 2012 11:06:13 AM org.glassfish.deployment.admin.DeployCommand execute
> INFO: test was successfully deployed in 18,014 milliseconds.
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:206)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.access$000(ServletMethodExecutor.java:43)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:99)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {code}
> Note that the deployment is successful, but the {{HTTPContext}} returned by the embedded GlassFish adapter contains the wrong port information. In this case, the http-listener-1/http-listener-2 combo was registered in domain.xml to listen on 8080/8181. When Arquillian established a connection to port 8181, the container obviously did not respond to plain text HTTP traffic, and quite obviously the client errored out.
--
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
11 years, 6 months
[JBoss JIRA] (ARQ-856) Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/ARQ-856?page=com.atlassian.jira.plugin.sy... ]
Vineet Reynolds commented on ARQ-856:
-------------------------------------
That would the {{arquillian-glassfish-embedded-3.1}} dependency. Your POM should look like:
{noformat}
....
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-glassfish-embedded-3.1</artifactId>
<version>1.0.0.CR4</version>
<scope>test</scope>
</dependency>
....
{noformat}
> Embedded GlassFish adapter may use an incorrect HTTP port when a custom domain configuration XML file is used
> -------------------------------------------------------------------------------------------------------------
>
> Key: ARQ-856
> URL: https://issues.jboss.org/browse/ARQ-856
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: GlassFish Containers
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Fix For: glassfish_1.0.0.CR4
>
>
> The embedded GlassFish container uses the default HTTP bind port of 8181, even though the user-supplied domain configuration XML file may specify a different HTTP port. This results in the following exception being thrown when the Arquillian client attempts to execute a test:
> {code}
> ...
> INFO: WELD-000900 SNAPSHOT
> 9 Apr, 2012 11:06:12 AM com.sun.enterprise.web.WebApplication start
> INFO: WEB0671: Loading application [test] at [/test]
> 9 Apr, 2012 11:06:13 AM org.glassfish.deployment.admin.DeployCommand execute
> INFO: test was successfully deployed in 18,014 milliseconds.
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:769)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:766)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:632)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:206)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.access$000(ServletMethodExecutor.java:43)
> at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:99)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
> {code}
> Note that the deployment is successful, but the {{HTTPContext}} returned by the embedded GlassFish adapter contains the wrong port information. In this case, the http-listener-1/http-listener-2 combo was registered in domain.xml to listen on 8080/8181. When Arquillian established a connection to port 8181, the container obviously did not respond to plain text HTTP traffic, and quite obviously the client errored out.
--
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
11 years, 6 months