You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ashish Kulkarni <ku...@yahoo.com> on 2002/08/28 19:54:52 UTC
Send parameters from one web application to other
Hi,
i have 2 web applications runnung on tomcat,say A and
B at some point i have to call a jsp B from A, and to
to send some parameters, one approcah is that i can
have an URL appended with the parameters
like http://localhost:8080/B/test.jsp?name=a
but i want to hide it from the user, or say if i have
to send a object from one web application to other.
how can i do it
Ashish
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Send parameters from one web application to other
Posted by Frank Mau <fr...@sun.com>.
Hi Ashish,
I think there are many ways to send these params, here are two of them:
1st. Set a global (for your domain not for your webapp and server) cookie
to identify your user or whatever -> guarantees in normal cases your
security. Create in a common database for your apps a key-value pair with
your needed data and send the key as a normal request-param (e.g.
Servlet?commonkey=XYZ5542)
2nd. Set a global cookie and store your data in a string value. If needed
encrypt them.
Regards
Frank
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 8/28/02, 7:54:52 PM, schrieb Ashish Kulkarni <ku...@yahoo.com>
zum Thema Send parameters from one web application to other:
> Hi,
> i have 2 web applications runnung on tomcat,say A and
> B at some point i have to call a jsp B from A, and to
> to send some parameters, one approcah is that i can
> have an URL appended with the parameters
> like http://localhost:8080/B/test.jsp?name=a
> but i want to hide it from the user, or say if i have
> to send a object from one web application to other.
> how can i do it
> Ashish
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Finance - Get real-time stock quotes
> http://finance.yahoo.com
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Extended authentication
Posted by Mike Skells <mi...@talk21.com>.
Hi Craig,
That is pretty much the implementation that I have been working on.
I am not an expert on the HTTP protocol, and less on the behavior of a
web container, so..
What is the best way to process the request in the same way as if it had
been processed without the security piece getting in the way. My current
implementation is storing in the session variable the value of the http
parameters, and re-attaching them when the second stage of the
authentication is completed, but I guess that the referrer header is not
'correct' (in that is is no longer the page that caused the reference),
and I don't know what else needs to be remembered, and patched.
The second problem that I have is more serious. If you consider the
following
Index.html -> /secure/foo.jsp ( which is protected)
This causes login.jsp (form based authentication) which posts the action
to j_security_check, whci hits the filter and gets redirected to
login2.jsp. When the user submits this, and assuming that the details
are correct I forward the request to the original request (but I cant
set the post data parameters, so I intercept the request within the
filter and supply the remembered http parameters, by modifying the
HttpServletRequest that is passed down the chain).
How do I defferntiate between a user refreshing that page, and a new
request. I guess that his logic is in the j_security_check
implementation so I was hoping that I could re-use it.
What is th mechanism that the j_security_check uses to get around this
problem?
Mike
> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Wednesday 28 August 2002 19:40
> To: Tomcat Users List
> Subject: Re: Extended authentication
>
>
>
>
> On Wed, 28 Aug 2002, Mike Skells wrote:
>
> > Date: Wed, 28 Aug 2002 19:21:49 +0100
> > From: Mike Skells <mi...@talk21.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: 'Tomcat Users List' <to...@jakarta.apache.org>
> > Subject: Extended authentication
> >
> > Hi,
> > I am developing an application where there is a need for extended
> > authentication, in addition to that of usernam/password, some
> > additional challenge/response
> >
> > Is there any way to protect a web app so that the extra
> parameters can
> > be prompted for in a 'standard' way
> >
> > I know that I can use froms based authentication, but how do I
> > separate the username/password validation from the
> forwarding of the
> > request.
> >
> > Ideally I would like to validate the usernam/password, and
> then take
> > the user to a subsiquent page that does additional validation.
> >
> > I had a look at JAAS to do this, but I cant see that this can be
> > plugged into a web app, without redeveloping the web app to
> explicitly
> > check, which rather defeats the purpose of the security
> system in the
> > first place.
> >
> > Is there any way to do this. All that I can think of is by using a
> > filter for all of the secure area which is processed after the
> > security check pass, but this means a re-implementation of the
> > facilities of the j_security_check which is hardly neat
> >
> > Any ideas
> >
>
> Doing any sort of validation that requires additional round
> trips to the user is going to be pretty challenging to
> implement, and is not supported portably by the servlet spec
> at this time. Basically, you are going to be on your own in
> the mean time.
>
> However, simulating your scenario for "subsequent page extra
> checking" doesn't seem that difficult. A strategy like this
> would probably work:
>
> * Define a session attribute that (if it exists) includes
> the results of your extra checking.
>
> * Add a Filter or some logic at the beginning of every page
> that routes the user to your extra page if this session
> attribute doesn't exist.
>
> * The servlet that responds to the "extra page" form post
> can create this session attribute and then redirect the
> user back to the menu.
>
>
> > Mike
> >
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Extended authentication
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 28 Aug 2002, Mike Skells wrote:
> Date: Wed, 28 Aug 2002 19:21:49 +0100
> From: Mike Skells <mi...@talk21.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: 'Tomcat Users List' <to...@jakarta.apache.org>
> Subject: Extended authentication
>
> Hi,
> I am developing an application where there is a need for extended
> authentication, in addition to that of usernam/password, some additional
> challenge/response
>
> Is there any way to protect a web app so that the extra parameters can
> be prompted for in a 'standard' way
>
> I know that I can use froms based authentication, but how do I separate
> the username/password validation from the forwarding of the request.
>
> Ideally I would like to validate the usernam/password, and then take the
> user to a subsiquent page that does additional validation.
>
> I had a look at JAAS to do this, but I cant see that this can be plugged
> into a web app, without redeveloping the web app to explicitly check,
> which rather defeats the purpose of the security system in the first
> place.
>
> Is there any way to do this. All that I can think of is by using a
> filter for all of the secure area which is processed after the security
> check pass, but this means a re-implementation of the facilities of the
> j_security_check which is hardly neat
>
> Any ideas
>
Doing any sort of validation that requires additional round trips to the
user is going to be pretty challenging to implement, and is not supported
portably by the servlet spec at this time. Basically, you are going to be
on your own in the mean time.
However, simulating your scenario for "subsequent page extra checking"
doesn't seem that difficult. A strategy like this would probably work:
* Define a session attribute that (if it exists) includes
the results of your extra checking.
* Add a Filter or some logic at the beginning of every page
that routes the user to your extra page if this session
attribute doesn't exist.
* The servlet that responds to the "extra page" form post
can create this session attribute and then redirect the
user back to the menu.
> Mike
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Extended authentication
Posted by Mike Skells <mi...@talk21.com>.
Hi,
I am developing an application where there is a need for extended
authentication, in addition to that of usernam/password, some additional
challenge/response
Is there any way to protect a web app so that the extra parameters can
be prompted for in a 'standard' way
I know that I can use froms based authentication, but how do I separate
the username/password validation from the forwarding of the request.
Ideally I would like to validate the usernam/password, and then take the
user to a subsiquent page that does additional validation.
I had a look at JAAS to do this, but I cant see that this can be plugged
into a web app, without redeveloping the web app to explicitly check,
which rather defeats the purpose of the security system in the first
place.
Is there any way to do this. All that I can think of is by using a
filter for all of the secure area which is processed after the security
check pass, but this means a re-implementation of the facilities of the
j_security_check which is hardly neat
Any ideas
Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>