Applying cookies/header settings to the JSFUnit sessions

[thesid]

When accessing the web application, the header is being checked for a userid, and in this case a SSO cookie is being set, that validates that the user is currently authenticated.

Within our web application we have a process that automatically runs certain tasks with help of JSFUnit.

Now the problem is that cactus seems to intiialize a session already even before the setUp method is being executed (all within the run method).

Is there any chance, to read the available cookies from the interactive user session, and 'inject' them to the cactus session?

The exception we currently face is:
org.apache.commons.httpclient.HttpMethodBase processResponseHeaders Cookie rejected: "$Version=0; SSOLogin=login; $Domain=.domain.tld; $Path=/". Domain attribute ".domain.tld" violates RFC 2109: host minus domain may not contain any dots

org.apache.commons.httpclient.HttpMethodBase processResponseHeaders Cookie rejected: "$Version=0; SSOURL=https:////ServletRedirector?Cactus_TestMethod=testJSFNavigation&Cactus_TestClass=de.docware.util.j2eeimpl.misc.JSFUnitWorkflowAutomation&Cactus_AutomaticSession=true&Cactus_Service=CALL_TEST; $Domain=.domain.tld; $Path=/". Domain attribute ".domain.tld" violates RFC 2109: host minus domain may not contain any dots

If there was a chance to reuse the authentication header/cookie from the interactive session, the error should be avoidable.

Any ideas?

[thesid]

Or would it be possible to prevent cactus from already creating the session before the setup method?So that there's chances to write cookies before calling the URL with webconversation?

[ssilvert]

Cactus does create a session, but you don't use it with JSFUnit. JSFUnit makes sure that you continue to use the same session created when you call the ServletTestRedirector or ServletTestRunner. Each time you create a new JSFClientSession or call WebConversationFactory.makeWebConversation(), JSFUnit will clear the session and add its control cookies to the WebConversation.

So, to add your own cookie before the first JSF request, you would do this:

WebConversation webConv = WebConversationFactory.makeWebConversation();
webConv.putCookie("mycookie", "myvalue");
JSFClientSession client = new JSFClientSession(webConv, "/index.jsf");

When we switch to HtmlUnit, you will do the same kind of thing with HtmlUnit's WebClient class.

Hope that helps,

Stan

[thesid]

Hi Stan,

I already rewrite the cookie for usage in websphere application server - but the problem is that cactus (or rather httpunit) already throws the cookie related exception (along with a parse exception in cactus) even before the setup method, where I would prepare the first JSF request ...

It is all within the "run" method - because the cactusURL - which is specified as system property - points to a server that requires SSO authentication - and this is why the URL is already redirected to the login page in the background.

If it wouldnt throw the exception already I'd not mind ;)

Would it be possibile to inject a totally different cactusURL to cactus at the later point wherere I would prepare the first JSF session?

So that at the first stage I'd use an irrelevant dummy URL or whatever (or empty if possibile) ... so that the SSO wouldnt be triggered and raise the exception in httpunit/cactus?

[ssilvert]

I think I understand your problem a little better now, but I'm not totally sure.

The cactus.contextURL is set inside JSFUnitFilter.doFilter(). So you could create your own version of that filter that does something else.

Give that a try and see if it fixes your problem. If so, I can add an init param to JSFUnitFilter that lets you override the value for cactus.contextURL.

Another solution might be to extend ServletTestCase and override the run() method so that it ignores this exception. Would that work for you?

Stan

[thesid]

Hi Stan,

we've traced this issue some more now. It seems like it's related to javascript. On the page that is being injected there's a javascript command, telling the browser to redirect the user to the login page.

Either it is the http unit in general that fails to handle this properly, or it is cause it can't handle minor html flaws. For instance, the type is not defined in the script tag. Unfortunately we have no influence on that redirect command syntax.

We could try to bypass the login-redirect page by jumping directly to the login page at the beginning.

After the login (if started with a hook url) the login page would redirect to the actual page again.

Would this still work with JSFUnit? The problem is that if JSFUnit would make each call using the cactusurl... it would always navigate over the login page, and force the login at each time - and not just once.

So something that needs to be achieved is:

"call login page once, that is at a totally different server, and then use the same session (as it is required for sso) for navigation. I guess the cactus url may have to be modifed at this stage - that is when the jsfclient sessions are being used. Not sure if that'd be possible with little efforts

I assume that when just ignoring the exception, the client would not get redirected properly, would it?

About the filter suggestion: What you do in the filter is setting the system property by the value that you found. The system property already is set prior to the jsfunit filter, so I'm not sure how that would modify the actual cactus contexturl for cactus.

I'm sorry if I appear a bit clueless, but to me it seems to be quite tricky...

[ssilvert]

"TheSid" wrote:
we've traced this issue some more now. It seems like it's related to javascript. On the page that is being injected there's a javascript command, telling the browser to redirect the user to the login page.

Either it is the http unit in general that fails to handle this properly, or it is cause it can't handle minor html flaws.

HttpUnit handles javascript so poorly that I had to turn it off. So with JSFUnit, javascript is not executed at all. Where I need javascript functionality, I have to emulate it in java.

But that is changing with the switch to HtmlUnit. With HtmlUnit, javascript will execute normally. I'm working through a single issue right now that is causing HtmlUnit to fail with RichFaces. As soon as that is finished and the HtmlUnit team puts out a snapshot, I'll put out a snapshot of JSFUnit that uses it.

Stan

[thesid]

Before I forget (I just noticed i didnt post that one yet)

These are the exceptions protocolled in the error log:

[5/16/08 4:11:46:843 CDT] 00000026 SystemErr R org.apache.cactus.util.ChainedRuntimeException: Failed to get the test results at [https://webwast2.ecorp.cat.com:8621/warranty/ServletRedirector]


org.apache.cactus.internal.client.ParsingException: Not a valid response. First 100 characters of the reponse: [function redirect() {window.location.replace("https://logi]
at org.apache.cactus.internal.client.WebTestResultParser.readRootElement(WebTestResultParser.java:106)
at org.apache.cactus.internal.client.WebTestResultParser.parse_aroundBody0(WebTestResultParser.java:62)
at org.apache.cactus.internal.client.WebTestResultParser.parse_aroundBody1$advice(WebTestResultParser.java:306)
at org.apache.cactus.internal.client.WebTestResultParser.parse(WebTestResultParser.java)
at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.callGetResult(DefaultHttpClient.java:218)
at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody0(DefaultHttpClient.java:87)
at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest_aroundBody1$advice(DefaultHttpClient.java:306)
at org.apache.cactus.internal.client.connector.http.DefaultHttpClient.doTest(DefaultHttpClient.java)


And this is the HTML which causes the exception. As it is more or less a javascript code within it, one asumption is taht it fails cause of the javascript. Another could be that... there's a html tag (which is invalid) ... or... that the tag has no type attribute.

function redirect() {window.location.replace("https://new.url.com?cwsURL=https:/
/old.url.com/jsp/main.jsp%3fdoAction=start");}

I will try to trace some more on this issue to find out which exactly is the problem.