servlet + login + cookies+ https

[gian]

Hi,
I m not expert for the things I'm going to tell you and maybe I'll be
inaccurate.My english is very poor ..so try to be patients..

I am developing an application that includes a
servlet.This servlet
make a redirect to another application (a site that
I know credentials.. username and password.)
What I have to do?

I think my servlet have to do a http post with the correct parameters
(the same post that is made
by a real user ) using a HttpUrlConnection .. (right?) and
then a response.sendRedirect (url).
or a forward?()the 2 applications are residents in the same websphere
application server)

The application where I want to log-on uses cookies in the process of
log-on (but I do not know how to handle them) and also the https ..
In your opinion is correct as a way of proceeding? "

Am I forgetting something?
Thanks a lot in advance.

Cheers
Gian

 

[Arne Vajhøj]

I m not expert for the things I'm going to tell you and maybe I'll be
inaccurate.My english is very poor ..so try to be patients..

I am developing an application that includes a
servlet.This servlet
make a redirect to another application (a site that
I know credentials.. username and password.)
What I have to do?

I think my servlet have to do a http post with the correct parameters
(the same post that is made
by a real user ) using a HttpUrlConnection .. (right?) and
then a response.sendRedirect (url).
or a forward?()the 2 applications are residents in the same websphere
application server)

The application where I want to log-on uses cookies in the process of
log-on (but I do not know how to handle them) and also the https ..
In your opinion is correct as a way of proceeding? "

Am I forgetting something?

If you want to redirect, then you just do a redirect. I believe you
can configure WebSphere to log you into all apps at once.

If you want to include content then you need to send the
HTTP request. If that is the case, then my suggestion is that
you go with Apache HttpClient instead of plain HttpURLConnection.

Arne

 

[Stanimir Stamenkov]

Sat, 31 Jul 2010 14:21:19 -0700 (PDT), /gian/:

The application where I want to log-on uses cookies in the process of
log-on (but I do not know how to handle them) and also the https ..

You may use the Apache's HttpClient which will handle the cookies
for you:

http://hc.apache.org/httpcomponents-client-4.0.1/index.html

 

[Tom Anderson]

I am developing an application that includes a servlet.This servlet make
a redirect to another application (a site that I know credentials..
username and password.) What I have to do?

It might be easiest to send a normal 200 response, containing some simple
HTML with a form to log into the second application, and a javascript
onload handler that submits the form. Essentially, simulate a normal login
from the browser.

Logging into the second application and then passing a cookie to the
client, as i think you want to do, might be possible, but it will fail if
the other application associates a client IP address with the cookie or
anything like that. Plus, i don't think you can handle an HTTPS login this
way.

tom

 

[gian]

Sat, 31 Jul 2010 14:21:19 -0700 (PDT), /gian/:


You may use the Apache's HttpClient which will handle the cookies
for you:

http://hc.apache.org/httpcomponents-client-4.0.1/index.html

yes i know but i cant use http client for version problem.httpclient
want java 5 and i have to use java 1.4

 

[gian]

It might be easiest to send a normal 200 response, containing some simple
HTML with a form to log into the second application, and a javascript
onload handler that submits the form. Essentially, simulate a normal login
from the browser.


tom

you say (if i understand well)your idea is servlet generate the html
and the javascript..
I will try ..

 

[Stanimir Stamenkov]

Sat, 31 Jul 2010 22:37:53 -0700 (PDT), /gian/:

yes i know but i cant use http client for version problem.httpclient
want java 5 and i have to use java 1.4

What about previous versions:

http://hc.apache.org/httpclient-3.x/index.html
http://hc.apache.org/downloads.cgi#Commons_HttpClient_3.1_legacy

 

[Arne Vajhøj]

yes i know but i cant use http client for version problem.httpclient
want java 5 and i have to use java 1.4

3.x should run on 1.4 and it has more or less the same functionality.

The API may not be quite as OO'ish, but ...

Arne

 

[Lew]

yes i know but i cant use http client for version problem.httpclient
want java [sic] 5 and i have to use java [sic] 1.4

Just out of curiosity, why are you stuck on an obsolete version? What is the
client's reasoning?

 

[gian]

yes i know but i cant use http client for version problem.httpclient
want java [sic] 5 and i have to use java [sic] 1.4

Just out of curiosity, why are you stuck on an obsolete version?  What is the
client's reasoning?

websphere AS

 

[gian]

I try ...but don't work
I receive a null pointer exception
....probably I have to understand better ..the headers and the cookies
in the http protocol ;-(

 

[Arne Vajhøj]

I try ...but don't work
I receive a null pointer exception
...probably I have to understand better ..the headers and the cookies
in the http protocol ;-(

No. I think you need to show some code and copy the exact exception
text etc. to make it possible for us to help you.

Arne

 

[Lew]

... have to use java [sic] 1.4

Just out of curiosity, why are you stuck on an obsolete version? What is the
client's reasoning?

websphere AS

In this particular case IBM maintains the JVM, mitigating the risk.

Many organizations who have lingered on Java 1.4 by dint of their application
servers are now upgrading the ASs to ones based on Java 5+. It is likely your
client has considered an upgrade to WAS and has a timeline in their plan for
when they'll move up. My guess is that the Java Enterprise world is a little
past the middle of the bell curve on that transition.

If their expected transition is near, and you might be pleasantly surprised,
sometimes you can plead a target release for a new feature or report or
whatever to wait until the new platform.

I've seen now on three large-scale projects huge opportunity as an employee to
position myself as a transition expert for Java 5 upgrades. Run a few
exercises at your desk - generify a core class and follow through all the
dependent consequences, for example. Whew!

Luckily you don't actually do that for initial transition. Don't even
@SuppressWarnings("unchecked") the legacy code. Let it warn you - it's good
for the project. Later you turn the new hires loose on a private branch and
tell 'em to generify store.general.foo.core.logic.* types and all consequent
dependencies. A team of three for a large project, two for a smaller one.

Once you yourself know the scope of the solution (how much overall team work
to transition - probably very little), you casually hit up the team lead with
the knowledge. Don't demand any action, just make sure they understand you
have an answer and are aware of the planned transition dates. Clue in the
team lead that it will be easy but don't you yourself tell that to anyone in
management.

Stay a little late after work each day and implement the transition for the
whole project on a private version-control branch. Debug the automation
thoroughly.

Privately email only the team lead that you have a completely debugged
transition branch ready to use as a starting point. Follow up with direct
verbal conversation. Follow their lead in how to use the prototype. A smart
team lead will make good advantages with it.

When a customer says, "We have to use product X", they often as in your case
present an opportunity to cash in on the transition to product Y from X. If
the transition is inevitable, as with the upgrade to Java 5 and later, and
your opportunism is good, then you can create a near certainty of advantage
for yourself. If the transition is already scheduled though not yet fully
planned by your customer/employer then your certain advantage is likewise
scheduled.

While a customer may superficially express a dogmatic restriction ("Thou shalt
use the version 1.4 of Java!"), they actually reveal an exploitable
opportunity ("We shall need help in six months to upgrade!").

 

[Arne Vajhøj]

yes i know but i cant use http client for version problem.httpclient
want java [sic] 5 and i have to use java [sic] 1.4

Just out of curiosity, why are you stuck on an obsolete version? What is the
client's reasoning?

websphere AS

5.1 or 6.0 ...

Arne

 

[Tom Anderson]

... have to use java [sic] 1.4

Just out of curiosity, why are you stuck on an obsolete version? What is
the
client's reasoning?

websphere AS

In this particular case IBM maintains the JVM, mitigating the risk.

Many organizations who have lingered on Java 1.4 by dint of their application
servers are now upgrading the ASs to ones based on Java 5+. It is likely
your client has considered an upgrade to WAS and has a timeline in their plan
for when they'll move up. My guess is that the Java Enterprise world is a
little past the middle of the bell curve on that transition.

If their expected transition is near, and you might be pleasantly surprised,
sometimes you can plead a target release for a new feature or report or
whatever to wait until the new platform.

I've seen now on three large-scale projects huge opportunity as an employee
to position myself as a transition expert for Java 5 upgrades. Run a few
exercises at your desk - generify a core class and follow through all the
dependent consequences, for example. Whew!

Luckily you don't actually do that for initial transition. Don't even
@SuppressWarnings("unchecked") the legacy code. Let it warn you - it's good
for the project. Later you turn the new hires loose on a private branch and
tell 'em to generify store.general.foo.core.logic.* types and all consequent
dependencies. A team of three for a large project, two for a smaller one.

Once you yourself know the scope of the solution (how much overall team work
to transition - probably very little), you casually hit up the team lead with
the knowledge. Don't demand any action, just make sure they understand you
have an answer and are aware of the planned transition dates. Clue in the
team lead that it will be easy but don't you yourself tell that to anyone in
management.

Stay a little late after work each day and implement the transition for the
whole project on a private version-control branch. Debug the automation
thoroughly.

Privately email only the team lead that you have a completely debugged
transition branch ready to use as a starting point. Follow up with direct
verbal conversation. Follow their lead in how to use the prototype. A smart
team lead will make good advantages with it.

When a customer says, "We have to use product X", they often as in your case
present an opportunity to cash in on the transition to product Y from X. If
the transition is inevitable, as with the upgrade to Java 5 and later, and
your opportunism is good, then you can create a near certainty of advantage
for yourself. If the transition is already scheduled though not yet fully
planned by your customer/employer then your certain advantage is likewise
scheduled.

While a customer may superficially express a dogmatic restriction ("Thou
shalt use the version 1.4 of Java!"), they actually reveal an exploitable
opportunity ("We shall need help in six months to upgrade!").

My hat is off to you sir.

tom

 

[Tom Anderson]

Sound fine..(but i dont understand the 200 response..)

200 is the HTTP status code for a normal, successful response. I just mean
you don't send a redirect.

you say (if i understand well)your idea is servlet generate the html and
the javascript..

That's what i'm saying. It's not a clean or elegant solution, but it's
possible that there are no clean or elegant solutions to your problem.

tom