j_security_check in relogin actionURL gives "400 Bad request"

[kmkale]

Hello,

Smartclient version SmartClient_v90p_2013-09-12

When using the Relogin process as explained in the Smartclient documentation, I have set the actionURL in

doLogin : function () {
isc.RPCManager.sendRequest({

to j_security_check

But posting to this url gives 400 bad request and tomcat does not log me in.

I have tried to set actionURL to loginSuccessMarker.html and also credentialsURL and variations as shown below:

credentialsURL: "j_security_check",
credentialsURL: "loginSuccessMarker.html",
actionURL: "loginSuccessMarker.html",
etc.

Only setting credentialsURL posts the form to IDAcall servlet which does nothing for authentication. Putting actionURL to loginSuccessMarker.html also does not do authentication. To me it looks like setting actionURL to j_security_check is the correct thing to do because in the server logs I can see that authentication has happened and doAuthenticate method has returned true, but then how do I handle the fact that tomcat does not like authentication posted directly to j_security_check and returns a 400 bad request without logging me in?

Edit :
I have tried setting loginSuccessMarker.html as the page returned by the server for http response code 400 via web.xml without success. I can see the loginSuccessMarker.html page returned in the dev console but I am still not authenticated by the container.
I have attached my relogin.js file. Please advise..

[Isomorphic]

What particular documentation are you looking at? We do have a wiki article on Tomcat Realm setup, including a login form that successfully calls j_security_check.

About the "400 Bad Request" error you're receiving in your environment, this probably isn't related to SmartClient. If you Google the error it seems to be something related to how you've set up redirects.

[kmkale]

Yes my main login page is very similar to the login form based example and works well.
And I am using JDBCRealm so the overall setup is same as the wiki example. And it works well for normal login.

During relogin based on the documentation at http://www.smartclient.com/docs/9.0/a/b/c/go.html#group..relogin I am using the relogin.js attached to my first post in this thread.
The relogin.js uses essentially the same form as used in my main login page which works. i.e. its action is set to j_security_check and its username & password params are called j_username & j_password.
But quoting from a mail thread here : http://mail-archives.apache.org/mod_mbox/tomcat-users/200604.mbox/%3C11D97B9CB01ECF44B8105B5628E7AEA6CE0A1D@PUN-EXG01.pun.s1.com%3E
<quote>
in form based login, access to the form
should never be done directly, that's because the container can accept a form login only if before the user tried to access an area requiring authentication. In simple terms, you see the form because the container has decided it required your credentials, not because you just wanted to log in.

Now in your case, after a session expire, when the user submit the form, tomcat just notice it gets an access to j_security_check while user session (which has been reset) show no track of a previous attempt to access a secure area needing authentication. The container then concludes naturally it is an attempt at accessing directly the j_security_check and just ignore the call, sending a 400.
At this step, tomcat has not saved the user/pass.
</quote>

This is exactly what is happening in the relogin case if we keep the actionURL as "j_security_check"

In our relogin case, when a users session has timed out and she tries to interact with a smartclient component, a request to http://flowell.localhost:9766/isomorphic/IDACall?isc_rpc=1&isc_v=v9.0p_2013-09-12&isc_xhr=1 is sent which triggers the loginRequired marker. And the relogin form is shown to the user. But when the loginForm in the attached relogin.js is submitted with correct username & password, gives me that '400' error.

So my questions are :
1) Is it correct to use j_security_check" as the actionURL of the loginForm in relogin.js?
2) I was hoping you could suggest a workaround for the problem described above specifically for the relogin case?

[Isomorphic]

1) this appears to be correct

2) the flow you describe - some protected resource is accessed, and the container shows the login form - is exactly what is happening here. IDACall is contacted, and the container sends back the login form in response. It is never displayed to the end user, but you should be able to verify this by just looking at the response to that request using eg Firebug.

Your problem might be that you are interfering with the container's automatic behavior here in some way, and returning the loginRequiredMarker in lieu of the login form. The entire purpose of the loginRequiredMarker is that it is safe to embed in your login form (has no effect on behavior when the login form is accessed during normal authentication).

So just embed it in the login form, reverse any other changes you've made relative to the wiki sample (which works and shows relogin working as well), and you should be fine.

[kmkale]

I have embedded the loginrequired script right after the body tag in my login.jsp. I have done no other change for relogin in login.jsp apart from this from the normal login ( working ) login.jsp

I can see that the full login page as rendered by login.jsp ( including the loginrequiredmarker) is returned in the response to the IDACall as expected, not just the loginrequiredmarker. The relogin correctly ignores this and shows the relogin form. But when this relogin form is submitted, I get a '400 bad request' back and tomcat has not logged me in :-(

[Isomorphic]

OK, it's not clear what more we can do for you at this point.

Your theory as to why you would receive a 400 error appears to be incorrect. The flow you are using *does* contact a protected resource.

We did not see a 400 error when setting up relogin with Tomcat.

We would suggest either:

1. trying to dig deeper into Tomcat docs and Tomcat forums to see if you can find a new possible reason why you get a 400 error

OR

2. setting things up exactly like the wiki article does, from scratch without any of your current code, so you can see correct operation. Then carefully compare that with your actual application to try to find differences.

[kmkale]

This is what I ended up doing in my doLogin :

doLogin : function () {
	//start a dummy call to loginSuccessMarker.html to avoid getting the '400 Bad Request' from tomcat if j_securty_check is directly called.
	//this call will be later cleared with isc.RPCManager.delayCall("clearTransaction",[logintransnum]); in loginReply functions
	//if(status ==isc.RPCResponse.STATUS_SUCCESS)
	isc.RPCManager.startQueue();
	isc.RPCManager.sendRequest({
		 actionURL: "loginSuccessMarker.html"
	 });
	 //store the transaction number for later clearTransaction call
	logintransnum=isc.RPCManager.getCurrentTransactionId();
	Log.logWarn("transactionid after sending req to loginSuccessMarker.html="+logintransnum);
	isc.RPCManager.sendQueue();
	
 isc.RPCManager.sendRequest({
     // let the RPCManager know not to delay this request and to discard this
     // request/response pair if the auth attempt fails.
     containsCredentials: true,
     // we must target the special loginSuccess.html file.  You can move it anywhere you
     // want, so long as your login attempts target it.
     //actionURL: isc.RPCManager.credentialsURL,
     actionURL: "j_security_check",
     
     // we're not going to privide any data beyond the username, password query params
     useSimpleHttp: true,
     showPrompt: false,

     // the actual credentials, from the form
     params : {
         j_username: this.loginForm.getValue("username")+"|"+clientid,
         j_password: this.loginForm.getValue("password")
     },
     callback : this.getID()+".loginReply(rpcResponse)"
 });
 
},

I create a dummy call to loginSuccessMarker.html in a new queue, note its transaction number and clear that transaction if auth succeeds.

This approach works as tomcat correctly redirects to loginSuccessMarker.html on auth success, and the the relogin process clears that transaction and resubmits all the saved transactions.

Please let me know what could be the side effects / problems due to using this approach?

[Isomorphic]

Aside from the fact that it shouldn't be necessary, you should probably be setting containsCredentials on that request, otherwise, when it encounters the loginRequiredMarker in the response, the loginRequired() handler is going to be called again.

This will also enable you to use the rpcRequest.callback to call clearTransaction() instead of just hoping the request makes it to the server before delayCall() fires.

[kmkale]

Thanks. Will try these suggestions.