Problem with form authentication

1,201 views
Skip to first unread message

Amanda Puff

unread,
Feb 23, 2015, 1:37:41 PM2/23/15
to rest-a...@googlegroups.com
I am not able to authenticate with the following code:

RestAssured.baseURI = "someBaseUri";
RestAssured.basePath = "someBasePath";
given().log().all().contentType("application/x-www-form-urlencoded").
auth().form("username", "password", new FormAuthConfig("/j_security_check", "j_username", "j_password")).
expect().
statusCode(200).
when().log().all().contentType("application/x-www-form-urlencoded").
   get("someUri");

I always get a 401 instead of a 200.  I expected auth().form() to POST to "someUri/j_security_check" after failing the initial security check and submitting the form data provided.  Logging indicates that there is only ever a GET to "someUri" and never a POST.  Also, the GET is either executed twice or is logged twice, not sure which.  Any idea what is going on?

Request method: GET
Request path: someUrl 
Proxy:      <none>
Request params: <none>
Query params: <none>
Form params:  <none>
Path params:  <none>
Multiparts:   <none>
Headers:    Accept=*/*
        Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Cookies:    <none>
Body:     <none>
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Set-Cookie: JSESSIONID=Z7PLHbTwHCrUSB+D28i2DxLT; Path=somePath
X-Powered-By: JSP/2.2
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 314
Date: Mon, 23 Feb 2015 18:13:24 GMT

<html>
  <body>
    <form enctype="application/x-www-form-urlencoded" method="post" action="j_security_check">
      <p>
        <span>Username:</span>
        <br clear="none"/>
        <input type="text" name="j_username"/>
      </p>
      <p>
        <span>Password:</span>
        <br clear="none"/>
        <input type="password" name="j_password"/>
      </p>
      <p>
        <input type="submit" value="Login"/>
      </p>
    </form>
  </body>
</html>
Request method: GET
Request path: someUrl
Proxy:      <none>
Request params: <none>
Query params: <none>
Form params:  <none>
Path params:  <none>
Multiparts:   <none>
Headers:    Accept=*/*
        Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Cookies:    <none>
Body:     <none>
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Set-Cookie: JSESSIONID=XBJCL-Z3el3ozxqsG0un5jHe; Path=somePath
X-Powered-By: JSP/2.2
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 314
Date: Mon, 23 Feb 2015 18:13:24 GMT

<html>
  <body>
    <form enctype="application/x-www-form-urlencoded" method="post" action="j_security_check">
      <p>
        <span>Username:</span>
        <br clear="none"/>
        <input type="text" name="j_username"/>
      </p>
      <p>
        <span>Password:</span>
        <br clear="none"/>
        <input type="password" name="j_password"/>
      </p>
      <p>
        <input type="submit" value="Login"/>
      </p>
    </form>
  </body>
</html>

Johan Haleby

unread,
Feb 24, 2015, 12:37:25 AM2/24/15
to rest-a...@googlegroups.com
Hmm that looks fine to me. To enable logging of the actual FormAuth request you need to do ".. , new FormAuthConfig(..).withLoggingEnabled()". Try that and see if you get some more clues.

--
You received this message because you are subscribed to the Google Groups "REST assured" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rest-assured...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Amanda Puff

unread,
Feb 24, 2015, 6:50:32 AM2/24/15
to rest-a...@googlegroups.com
The following is the log output from what you suggested.  I see now that the POST is happening, but unfortunately, it is happening in the wrong order and against the wrong URI.  We need the initial GET to occur first, which will respond with the authentication form.  Then, we need to POST to that same URI but with /j_security_check appended to the end of the URI.  Then, we will get a redirect back with the response from the original GET.  

I don't really know enough about form authentication best practices to know if our implementation is substandard.  Do you know if there is a configuration we can use to make this work or if REST Assured does not support our authentication implementation?

Request method: POST
Request path: baseURI/basePath/j_security_check
Proxy: <none>
Request params: <none>
Query params: <none>
Form params: j_username=username
j_password=password
Path params: <none>
Multiparts: <none>
Headers: Accept=*/*
Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Cookies: <none>
Body: <none>
HTTP/1.1 408 Request Timeout
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 646
Date: Tue, 24 Feb 2015 11:39:14 GMT
X-Cnection: close
Set-Cookie: BIGipServersp_test=1533585600.36895.0000; path=/
Vary: Accept-Encoding
Content-Encoding: gzip
Connection: Keep-Alive

<html>
  <head>
    <title>JBoss Web/7.4.8.Final-redhat-4 - JBWEB000064: Error report</title>
    <style>&lt;!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--&gt;</style>
  </head>
  <body>
    <h1>JBWEB000065: HTTP Status 408 - JBWEB000005: The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser</h1>
    <hr noshade="noshade" size="1"/>
    <p>
      <b>JBWEB000309: type</b>
 JBWEB000067: Status report    </p>
    <p>
      <b>JBWEB000068: message</b>
      <u>JBWEB000005: The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser</u>
    </p>
    <p>
      <b>JBWEB000069: description</b>
      <u>JBWEB000128: The client did not produce a request within the time that the server was prepared to wait.</u>
    </p>
    <hr noshade="noshade" size="1"/>
    <h3>JBoss Web/7.4.8.Final-redhat-4</h3>
  </body>
</html>
Request method: GET
Request path: baseUri/basePath/codes/search
Proxy: <none>
Request params: <none>
Query params: <none>
Form params: <none>
Path params: <none>
Multiparts: <none>
Headers: Accept=*/*
Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Cookies: BIGipServersp_test=1533585600.36895.0000
Body: <none>
HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Set-Cookie: JSESSIONID=kAnPL1s-GzSMueQOW7-yCnSn; Path=somePath
X-Powered-By: JSP/2.2
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 314
Date: Tue, 24 Feb 2015 11:39:14 GMT

<html>
  <body>
    <form enctype="application/x-www-form-urlencoded" method="post" action="j_security_check">
      <p>
        <span>Username:</span>
        <br clear="none"/>
        <input type="text" name="j_username"/>
      </p>
      <p>
        <span>Password:</span>
        <br clear="none"/>
        <input type="password" name="j_password"/>
      </p>
      <p>
        <input type="submit" value="Login"/>
      </p>
    </form>
  </body>
</html>


Johan Haleby

unread,
Feb 25, 2015, 1:59:20 AM2/25/15
to rest-a...@googlegroups.com
Try not adding a FormAuthConfig then REST Assured will try to automatically get things right (but an extra request needs to be made under the hood the the HTML page needs to be parsed). If this doesn't work you would probably need to write your own AuthFilter.

Marko Nikolić

unread,
May 18, 2015, 12:04:06 AM5/18/15
to rest-a...@googlegroups.com
I had a similar problem with authenticating on Tomcat server with RestAssured, I guess the problem is the same as on JBoss.

It seems to me that RestAssured does not directly supports Tomcat form authentication method. POSTing to j_security_check is not the only needed step for proper authentication; it is also required to handle session IDs in the proper way. As far as I can tell, RestAssured does not honor session IDs in the manner that Tomcat expects.

The step I have used and managed to authenticate are:

1. create a get request on some resource, preserve session ID
2. post to j_security_check using session ID from previous step
3. create a get request on the same resource from step 1, and preseve returned session ID

Session ID from the last step is the most important - it should be supplied with all consequtive requests and everything will work correctly - this is ID of the "authenticated" session. The above three steps can be stored in @BeforeClass method, so it will execute and authenticate before all tests.

You can find more details and code example on the following link: http://www.iten.rs/using-restassured-with-tomcat-form-authentication/ .

Hope this will help,

Marko

Johan Haleby

unread,
May 18, 2015, 2:42:52 AM5/18/15
to rest-a...@googlegroups.com
Does it help if you also include the SessionFilter?

Marko Nikolić

unread,
May 21, 2015, 8:25:02 AM5/21/15
to rest-a...@googlegroups.com
Including SessionFilter would make code more clear, but will not solve the problem. In the code given on the link below I am extracting session id using sessinId() method and setting cookie JSESSIONID as needed. I guess this is similar to what SessionFilter is doing internaly.

The problem is that form() method can not be used for loging to server which uses Tomcat form authentication method, because the sessionId changes as described in the steps I have posted. Once the authenticated sessionId is returned, it can be set to RestAssured.sessionId and used for all subsequent requests.

Marko
Reply all
Reply to author
Forward
0 new messages