share data between two tomcat contexts?

[Laura Schmidt]

Hi,

I want to share some data between two tomcat applications running on the
same server.

There are a lot of suggestions proposing to set crossContext="true" in
the corresponding context elements in the server.xml.

However, I do not have access to tomcat's server.xml. I only can modify
the war/WEB-INF/web.xml of my GWT app, which is the <web-app> element.

Are there any solutions?

Thank you
Laura

[markspace]

On 5/16/2014 4:32 PM, Laura Schmidt wrote:
>
> Are there any solutions?


I'd have to guess "no." Tomcat (how do you know it's Tomcat and not
another container?) is designed to prevent this sort of thing, so I
can't see how they'd leave a hole open for apps to interfere with each
other.

At this point consider using your own server. Amazon has micro
instances for cheap, and Tomcat, Apache and OpenJDK are easy downloads.
It's somewhat more work but worth it imo for the extra control it
gives you.

[Arne Vajhøj]

There are several options:
* store in database.
* store in file on disk.
* fetch from one app to another app via web service.

For the second bullet you can use memory mapped file - it
should perform very well (or so they say - I have never tried
it myself).

Arne

[Laura Schmidt]

On 05/17/2014 01:41 AM, markspace wrote:
> On 5/16/2014 4:32 PM, Laura Schmidt wrote:

>> Are there any solutions?

> At this point consider using your own server.

Ok, but how would this work over time?

Assume an app "FirstApp". What would I insert into the server.xml?

And then, what happens, when I update the app, e. g. undeploy and
redeploy it? There will be a time span where server.xml references to an
app that does not exist?

Thank you
Laura

[markspace]

On 5/16/2014 5:19 PM, Laura Schmidt wrote:
> Assume an app "FirstApp". What would I insert into the server.xml?

That's a whole different can of worms there. Assume you need to read
the docs.

After you have your own server, you can do anything you like. You can
open up a named pipe and use that, server.xml won't be involved.

[Laura Schmidt]

On 05/17/2014 02:40 AM, markspace wrote:
> On 5/16/2014 5:19 PM, Laura Schmidt wrote:
>> Assume an app "FirstApp". What would I insert into the server.xml?

> That's a whole different can of worms there.

I don't get it:

First, I said that I heared of a solution where you have to enable
"crossContext" in the server.xml file, but I don't have access to this file.

Then, you answered that I should get my own server. I understood that I
should do this to be able to change my server.xml.

Are you pointing to another solution, other than enabling cross context
in server.xml?

For your convenience, here is a description of the cross context solution:

http://blog.imaginea.com/cross-context-communication-between-web-applications/

However, this article refers to a context element:
<Context crossContext="true">

But this statement does not refer to a special web app.
That's why I asked about server.xml.

Laura

[Leif Roar Moldskred]

Laura Schmidt <l...@mailinator.com> wrote:
> Hi,
>
> I want to share some data between two tomcat applications running on the
> same server.
>

Are there performance demands that prevents you from having one
application just make HTTP requests to the other and ask for the data
when it needs it?

--
Leif Roar Moldskred

[Josip Almasi]

I suppose so.
Now that I've looked at the article (interesting one, thanks!), caller
app may fail when context is unavailable during redeployment, in a
number of ways.
Also, redeployment of called app might delay, maybe even fail, for
caller app keeps reference to called classloader.
So it's up to you to make that time span shorter - don't store
references to called context and classloader and object and methods
anywhere, so they become unreachable as soon as possible.
Reflection calls are never cached, you'll always get references to fresh
classes, objects and methods.

Regards...

[Robert Klemme]

On 17.05.2014 01:45, Arne Vajhøj wrote:

> There are several options:
> * store in database.
> * store in file on disk.
> * fetch from one app to another app via web service.

If applications are more tightly bound than that then the natural thing
would be to merge them into one application. What's best probably
depends on the nature of applications and the data that needs to be
exchanged.

Kind regards

robert

[Laura Schmidt]

Well, the first application is an existing legacy application where
users can login.

When logged in, they are informed about a relaunch of the application
and they can follow a link to it.

Within the new application I would like to know the identity of the user
who is coming from the legacy application. This is why I would like to
access the other one's sesson.

Laura

[lipska the kat]

It *sounds* like you are talking about single sign on.
AFAIK you need access to ../conf/server.xml to implement this.

I use contexts to store data (mostly images) outside the scope of the
current context. So in

/opt/apache-tomcat-7.0.42/conf/Catalina/localhost

I have two xml files

images.xml and sitemap.xml

here's the xml for sitemap

<Context path="/sitemap" docBase="/var/sitemap" crossContext="true"/>

now, I can generate a new sitemap, store it somewhere where it won't be
deleted when I redeploy the webapp and access it like

http://www.mydomain.com/sitemap/mysitemap.xml

I'm not sure you can access a session in one web app from another web
app anyway, even if you do have access to it's context.

You might do better asking on the tomcat users mailing list

http://tomcat.apache.org/lists.html#tomcat-users

rgds



--
Lipska the Kat�: Troll hunter, sandbox destroyer,
treacherous feline and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[Leif Roar Moldskred]

Laura Schmidt <l...@mailinator.com> wrote:
>
> Well, the first application is an existing legacy application where
> users can login.
>
> When logged in, they are informed about a relaunch of the application
> and they can follow a link to it.
>
> Within the new application I would like to know the identity of the user
> who is coming from the legacy application. This is why I would like to
> access the other one's sesson.

I don't really think there's any serviceable way to do that without
involving the server.xml. While there are ways you can transfer the
information across, I suspect it's going to be all but impossible to
do it securely.

--
Leif Roar Moldskred

[Chris Uppal]

Laura Schmidt wrote:

> I want to share some data between two tomcat applications running on the
> same server.
>
> There are a lot of suggestions proposing to set crossContext="true" in
> the corresponding context elements in the server.xml.
>
> However, I do not have access to tomcat's server.xml. I only can modify
> the war/WEB-INF/web.xml of my GWT app, which is the <web-app> element.

Can't you just set up an end-point as part of each service that is used by the
other to transfer data ? Should be pretty efficient if the two services are
actually in the same container.

-- chris

[Chris Uppal]

Laura Schmidt wrote:

> When logged in, they are informed about a relaunch of the application
> and they can follow a link to it.
>
> Within the new application I would like to know the identity of the user
> who is coming from the legacy application. This is why I would like to
> access the other one's sesson.

Would OAuth do the trick here ?

-- chris

[Robert Klemme]

On 17.05.2014 13:22, Laura Schmidt wrote:
> On 05/17/2014 08:35 AM, Leif Roar Moldskred wrote:
>> Laura Schmidt <l...@mailinator.com> wrote:

>>> I want to share some data between two tomcat applications running on the
>>> same server.

> Well, the first application is an existing legacy application where
> users can login.
>
> When logged in, they are informed about a relaunch of the application
> and they can follow a link to it.

Wouldn't it be much easier to just immediately redirect users to the new
application before login? Then they can login at the new application
directly. I'm sure you have login functionality in place because you
also need to handle user coming directly to the new application.

Alternatively you can remove the old application completely and provide
a login form in the new application under the URL of the old app's login
page.

Cheers

robert

[lipska the kat]

On 17/05/14 12:22, Laura Schmidt wrote:

If all you want is the identity(username) of the logged in user
you can get it from the request.

When the user clicks the link to the new app they actually end up at a
servlet in the legacy app, in the servlet you can get the login name by
calling HttpServletRequest#getRemoteUser()

You then build your request dispatcher to forward the request to a
resource in the new app, appending the username to the request string or
adding it as an attribute, maybe you could encrypt the username at this
point.

when the request arrives at the new app you extract the username ...
and 'Roberts your relative', you know the username of the user that
logged into the legacy app.

Completely insecure of course but it depends on the situation.
and I have no idea if you can actually forward to a different app in
this way as I've never tried it.


--
lipska the kat - treacherous feline.
Proudly nominated for IPOTY 2014 - LIGAF
GNU/Linux user #560883 - linuxcounter.net

[Brixomatic]

In article <ll7gok$ghl$1...@news.m-online.net>, Laura Schmidt
(l...@mailinator.com) says...

> Well, the first application is an existing legacy application where
> users can login.
>
> When logged in, they are informed about a relaunch of the application
> and they can follow a link to it.
>
> Within the new application I would like to know the identity of the user
> who is coming from the legacy application. This is why I would like to
> access the other one's sesson.

Why not have the first application return a customized link that
contains some individual random token.
Have it send that token to the second application using a web service or
by updating some table in a shared database.
When the second application comes in with that link, like:
http://x.example/index.html?token=128739987216
check that token against the recent tokens and log him on without asking
for credentials, if the token matches a present one.
Don't forget to expire tokens after a few minutes and after use, to
avoid attackers using an old or active token and mind that the tokens
should be big enough and randomly generated, so an attackers cannot just
try a bunch of random tokens for quite some time, waiting for a real
user to get a same one by chance.

Kind regards,
Wanja

--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]