April 2013 - arquillian-issues - Jboss List Archives

[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication

by Oliver Bock (JIRA)

[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ] Oliver Bock edited comment on ARQ-1370 at 4/9/13 6:53 PM: ---------------------------------------------------------- Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-) {quote} I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective {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). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow. 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. IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? What do you reckon? Seems like an interesting problem :-) was (Author: brevilo): Great, thanks for the doc pointers! The Arquillian GitHub wiki at [2] would have been the last place for me to look for such Warp details ;-) {quote} I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective {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). You know better than me whether that kind of client-side tests is also affected by the new {{CommandService}} infrastructure/workflow. 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. IMHO, such a workaround would be less optimal, however, because a functional JSF test naturally involves the web app's container, including potential security measures in place (like SSL or authentication). Thus it would be nice to run such tests in their actual environment, without the need for a parallel security setup that (potentially) needs to be kept in sync with the container's setup in order to produce meaningful test results (without superfluous artefacts). This is what Arquillian is all about after all, right? :-) What do you think? > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-13) Provide an example that shows Arquillian being used with Ant

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/ARQ-13?page=com.atlassian.jira.plugin.sys... ] Pete Muir commented on ARQ-13: ------------------------------ I've increased the priority to Critical as this is a requirement for Seam 2.3 SeamTest to be fully supported. > Provide an example that shows Arquillian being used with Ant > ------------------------------------------------------------ > > Key: ARQ-13 > URL: https://issues.jboss.org/browse/ARQ-13 > Project: Arquillian > Issue Type: Feature Request > Components: Examples/Showcase > Reporter: Pete Muir > Assignee: Jason Porter > Priority: Critical > Fix For: 2.0.0.Beta1 > > > This example needs to use vanilla Ant. > A second example could show the use of Ant + Maven Ant Tasks or Ivy. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-13) Provide an example that shows Arquillian being used with Ant

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/ARQ-13?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated ARQ-13: ------------------------- Priority: Critical (was: Major) > Provide an example that shows Arquillian being used with Ant > ------------------------------------------------------------ > > Key: ARQ-13 > URL: https://issues.jboss.org/browse/ARQ-13 > Project: Arquillian > Issue Type: Feature Request > Components: Examples/Showcase > Reporter: Pete Muir > Assignee: Jason Porter > Priority: Critical > Fix For: 2.0.0.Beta1 > > > This example needs to use vanilla Ant. > A second example could show the use of Ant + Maven Ant Tasks or Ivy. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-639) Add ability to postpone initialization of non-managed deployments annotated @Deployment(managed=false)

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/ARQ-639?page=com.atlassian.jira.plugin.sy... ] Dominik Pospisil resolved ARQ-639. ---------------------------------- Resolution: Out of Date > Add ability to postpone initialization of non-managed deployments annotated @Deployment(managed=false) > ------------------------------------------------------------------------------------------------------ > > Key: ARQ-639 > URL: https://issues.jboss.org/browse/ARQ-639 > Project: Arquillian > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.0.0.CR5 > Reporter: Dominik Pospisil > Fix For: 2.0.0.Beta1 > > > Currently deployments annotated using @Deployment(managed=false) are initialized prior to test case execution (EventTestRunnerAdaptor.beforeClass:80). Some test scenarios require that the initialization of the deployment is postponed until the actual deployment is performed using Deployer.deploy() call. > It would be nice if the @Deploymnent(managed=false) method is called during Deployer.deploy() call by default or if there is an option to specify when the initialization should be performed. > This way the content of the deployment may be constructed / updated during test case runtime using information which may not be available before test execution. -- 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, 9 months

1
0
0 / 0

[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č edited comment on ARQ-1370 at 4/8/13 5:06 PM: --------------------------------------------------------- Hey Oliver, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are). Generally: * {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [[2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUnit.NG)]]) ** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective * {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet) ** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either. was (Author: lfryc): Hey Oliver, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are). Generally: * {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUni...) ** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective * {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet) ** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either. > 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, 9 months

1
0
0 / 0

[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, this might not be ideal solution at all, just the idea which came from my mind (and just to make it clear, I'm not really a guy into security like you are). Generally: * {{Alpha2}} didn't need to know anything about the underlying communication (see [[1|https://github.com/lfryc/arquillian.github.com/blob/962cf48dee8ed90f42421ac240704a1379caf3a4/docs/warp.adoc]], [2|https://github.com/arquillian/arquillian-organization/wiki/Warp-(JSFUni...) ** I actually think that any SSL communication wouldn't work in Warp in Alpha2, beucase Warp is a Man in the Middle from the SSL handshake perspective * {{Alpha3-SNAPSHOT}} no longer communicates just when a client request is triggered but it creates a request also when test is finished in order to collect server's coverage metrics (through the CommandService servlet) ** and here comes a problem - the request for CommandService is redirected and forced to open a SSL request which fails, because the SSL handshake I guess your client-side tools worked because you used a HTTP client which handled SSL communication. The in-container and Warp test failed, because they weren't able to establish SSL communication. Now the client-side tests fails because CommandService aren't able to establish SSL communication either. > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQ-1370) Warp: support SSL for CommandService using untrusted communication

by Oliver Bock (JIRA)

[ https://issues.jboss.org/browse/ARQ-1370?page=com.atlassian.jira.plugin.s... ] Oliver Bock commented on ARQ-1370: ---------------------------------- Sure, you're welcome. Regarding your proposed solution (referenced in the description): without admittedly knowing Warp's internals, this looks more like a workaround than a solution. The root cause of this problem seems to be that {{Alpha3}} requires a dedicated custom SSL context (or TrustManager, respectively) while {{Alpha2}} was able to make use of the container's existing SSL context as described in ARQ-1365 and the forum thread (referenced above). The question is: why is that and would it be possible to let {{CommandService}} reuse the existing SSL context as well? Just ignore my comment if I'm totally mistaken ;-) > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-283) Create blog entry about Graphene vs WebDriver

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-283?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-283: ----------------------------------- Hey Juraj, this will be awesome. > Create blog entry about Graphene vs WebDriver > --------------------------------------------- > > Key: ARQGRA-283 > URL: https://issues.jboss.org/browse/ARQGRA-283 > Project: Arquillian Graphene > Issue Type: Task > Components: doc > Reporter: Juraj Húska > Assignee: Juraj Húska > Fix For: 2.0.0.Alpha4 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > Create blog entry about core differences between WebDriver and Graphene. It should summarize all Graphene features to promote them. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-282) Create Graphene guide on arquillian.org

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-282?page=com.atlassian.jira.plugin... ] Lukáš Fryč edited comment on ARQGRA-282 at 4/8/13 6:04 AM: ----------------------------------------------------------- Hey Juraj, this sounds great. Only my note to your concern: showcasing of the Graphene features should be minimal but introducing enough to allow understanding - the rest can be solved by referencing documentation ("Note: for more info...") Let's start with it and focus on propagating WebDriver/Graphene best practices (other features we don't intend to demonstrate can be incorporated as side notes). was (Author: lfryc): Hey Juraj, this sounds great. Only my note to your concern: showcasing of the Graphene features should be minimal but introducing enough to allow understanding - the rest can be solved by referencing documentation ("Note: for more info...") > Create Graphene guide on arquillian.org > --------------------------------------- > > Key: ARQGRA-282 > URL: https://issues.jboss.org/browse/ARQGRA-282 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: doc > Reporter: Juraj Húska > Assignee: Juraj Húska > Fix For: 2.0.0.Alpha4 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > Possible option is to alter functional testing guide which is here: > http://arquillian.org/guides/functional_testing_using_drone/ -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ARQGRA-282) Create Graphene guide on arquillian.org

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/ARQGRA-282?page=com.atlassian.jira.plugin... ] Lukáš Fryč commented on ARQGRA-282: ----------------------------------- Hey Juraj, this sounds great. Only my note to your concern: showcasing of the Graphene features should be minimal but introducing enough to allow understanding - the rest can be solved by referencing documentation ("Note: for more info...") > Create Graphene guide on arquillian.org > --------------------------------------- > > Key: ARQGRA-282 > URL: https://issues.jboss.org/browse/ARQGRA-282 > Project: Arquillian Graphene > Issue Type: Feature Request > Components: doc > Reporter: Juraj Húska > Assignee: Juraj Húska > Fix For: 2.0.0.Alpha4 > > Original Estimate: 3 hours > Remaining Estimate: 3 hours > > Possible option is to alter functional testing guide which is here: > http://arquillian.org/guides/functional_testing_using_drone/ -- 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, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues April 2013