Understand J_Security_Check by coding in Ruby

Found a good article about ruby access J_security_check, which gave me a clear view about j_security_check. My revised ruby code looks like this:

     def form_auth_demo
res = Net::HTTP.new(host, port).start do |http|
#make the initial get to get the JSESSION cookie
get = Net::HTTP::Get.new(path_to_jsp)
response = http.request(get)
# get original cookie contains jsessionid=blahblahblah
cookie = response.response['set-cookie']

#authorize
post = Net::HTTP::Post.new(‘/MyApp/j_security_check’)
post.set_form_data({‘j_username’=>’XX’, ‘j_password’=>’XX’})
post['Cookie'] = cookie
response = http.request(post)

# one way to check result
# puts ‘Code = ‘ + response.code
# puts ‘Message = ‘ + response.message

# another way to check result
# case response
# when Net::HTTPSuccess
# puts ‘Login OK’
# when Net::HTTPRedirection
# puts    ’redirect to ‘ + response['location']
# else
# res.error!
# end

# grab the new cookie generated from server contains jadid=XXX
# This is extra line I added, I think the reason is because we are using EAServer.
cookie2 = response.response['set-cookie']

# replace the old one with this authenticated new cookie.
get['Cookie'] = cookie2

response = http.request(get)

puts ‘Code = ‘ + response.code
puts ‘Message = ‘ + response.message
# puts response.body

end
end

Now I know a little bit more about what happens in  j_security_check.

1. Client send request, sever check if client has been authenticated. If not, send a JSessionID back to client, then redirect to login page.
2. Client input credentials, submit form. After validate, server generate a JadID (I think this might be a EAServer unique feature.
3. Client has to use this updated cookie to continue work.