You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2009/02/05 22:49:31 UTC
RealmBase's 'Container' requirement (revisited)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Back in July, I asked about RealmBase requiring a Container object in
order to function properly. This has to do with using securityfilter
with Tomcat's built-in Realms.
Here is a reference to the original thread:
http://marc.info/?t=121751323100003&r=1&w=2
I've started playing around with implementing a trivial ContainerBase
subclass and I'm running into trouble again so I was hoping that some of
the TC devs could weigh-in.
My trivial ContainerBase subclass looks like this:
private static class DummyContainer
extends org.apache.catalina.core.ContainerBase
{
public String getInfo()
{
return "securityfilter_dummy_container/1.0";
}
}
...and I essentially create a new Realm object and then call
Realm.setContainer(). It looks like I'm getting farther than I was
before, but I'm still getting errors deep down in Tomcat's internals.
I'm getting an NPE in the DataSourceRealm (which is what I'm using as an
example):
java.lang.NullPointerException
at
org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:402)
at
org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:283)
at
org.securityfilter.realm.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java:105)
The method in question (DataSourceRealm.open) looks like this:
protected Connection open() {
try {
Context context = null;
if (localDataSource) {
context = ContextBindings.getClassLoader();
context = (Context) context.lookup("comp/env");
} else {
StandardServer server =
(StandardServer) ServerFactory.getServer();
context = server.getGlobalNamingContext();
}
DataSource dataSource =
(DataSource)context.lookup(dataSourceName); /// THIS IS LINE 402
return dataSource.getConnection();
} catch (Exception e) {
// Log the problem for posterity
containerLog.error(sm.getString("dataSourceRealm.exception"), e);
}
return null;
}
Since I've included catalina.jar and catalina-optional.jar in my webapp,
classes like ServerFactory and friends haven't been initialized since
they are dormant in my webapp. The "real" ServerFactory class being
loaded by Tomcat's server ClassLoader are, I'm sure, doing quite well.
My question is this: how much of Tomcat's internals do I have to mock-up
in order to get a Realm working outside of a legitimately running
server? That sound like a ridiculous question, but securityfilter used
to work with Tomcat Realms back in the day (4.x?) and now they don't
(definitely 5.5, possibly 5.0 and 6.0 as well) because of this reliance
upon more of Tomcat internals.
Should I continue down this road of trying to prop-up a Tomcat skeleton
server inside the webapp's space, or would it be better to discontinue
support for this feature?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmLXusACgkQ9CaO5/Lv0PDa3wCgryhZIOIxJg1BrZu/cvaExoka
y2wAn1Anr7EtHdXVj4merPdUmWkAwDCO
=Hwel
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: RealmBase's 'Container' requirement (revisited)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
Just a bump since I didn't get any responses other than a question from
Chuck.
Mark? Filip? Bill? Tim? I'd even go for a flame from Remy. ;)
Thanks,
- -chris
On 2/5/2009 4:49 PM, Christopher Schultz wrote:
> All,
>
> Back in July, I asked about RealmBase requiring a Container object in
> order to function properly. This has to do with using securityfilter
> with Tomcat's built-in Realms.
>
> Here is a reference to the original thread:
> http://marc.info/?t=121751323100003&r=1&w=2
>
> I've started playing around with implementing a trivial ContainerBase
> subclass and I'm running into trouble again so I was hoping that some of
> the TC devs could weigh-in.
>
> My trivial ContainerBase subclass looks like this:
>
> private static class DummyContainer
> extends org.apache.catalina.core.ContainerBase
> {
>
> public String getInfo()
> {
> return "securityfilter_dummy_container/1.0";
> }
> }
>
> ...and I essentially create a new Realm object and then call
> Realm.setContainer(). It looks like I'm getting farther than I was
> before, but I'm still getting errors deep down in Tomcat's internals.
> I'm getting an NPE in the DataSourceRealm (which is what I'm using as an
> example):
>
> java.lang.NullPointerException
> at
> org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:402)
> at
> org.apache.catalina.realm.DataSourceRealm.authenticate(DataSourceRealm.java:283)
> at
> org.securityfilter.realm.catalina.CatalinaRealmAdapter.authenticate(CatalinaRealmAdapter.java:105)
>
> The method in question (DataSourceRealm.open) looks like this:
>
> protected Connection open() {
>
> try {
> Context context = null;
> if (localDataSource) {
> context = ContextBindings.getClassLoader();
> context = (Context) context.lookup("comp/env");
> } else {
> StandardServer server =
> (StandardServer) ServerFactory.getServer();
> context = server.getGlobalNamingContext();
> }
> DataSource dataSource =
> (DataSource)context.lookup(dataSourceName); /// THIS IS LINE 402
> return dataSource.getConnection();
> } catch (Exception e) {
> // Log the problem for posterity
>
> containerLog.error(sm.getString("dataSourceRealm.exception"), e);
> }
> return null;
> }
>
> Since I've included catalina.jar and catalina-optional.jar in my webapp,
> classes like ServerFactory and friends haven't been initialized since
> they are dormant in my webapp. The "real" ServerFactory class being
> loaded by Tomcat's server ClassLoader are, I'm sure, doing quite well.
>
> My question is this: how much of Tomcat's internals do I have to mock-up
> in order to get a Realm working outside of a legitimately running
> server? That sound like a ridiculous question, but securityfilter used
> to work with Tomcat Realms back in the day (4.x?) and now they don't
> (definitely 5.5, possibly 5.0 and 6.0 as well) because of this reliance
> upon more of Tomcat internals.
>
> Should I continue down this road of trying to prop-up a Tomcat skeleton
> server inside the webapp's space, or would it be better to discontinue
> support for this feature?
>
> Thanks,
> -chris
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmSMawACgkQ9CaO5/Lv0PDLpQCfbcL+tfBeYvtkLs0Hl7dqaKmj
vbYAn0Djma8LF8+bv1r3mVovuc572Cb3
=ZW3z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: RealmBase's 'Container' requirement (revisited)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:chris@christopherschultz.net]
>> Subject: RealmBase's 'Container' requirement (revisited)
>
>> Should I continue down this road of trying to prop-up a
>> Tomcat skeleton server inside the webapp's space
>
> I'm confused (seems to be happening a lot lately): Tomcat already
> supports context-specific <Realm> usage, so what is the real capability
> you're providing? Would JMX allow you to create (and destroy) a
> context-specific Realm on the fly?
I'm trying to allow users of securityfilter to use Tomcat's pre-built
Realm implementations. securityfilter borrows the "realm" concept from
Tomcat but provides (IMO) much improved flexibility (outside the servlet
spec, of course) to form authentication. You can think of securityfilter
as a replacement for the container-based authentication and
authorization framework, without the Realm implementations. The
nomenclature is unfortunate, since Tomcat's Realms (and therefore
securityfilter's) are really authenticators... or maybe credential
validators if you prefer.
Basically, we have a CatalinaRealmAdapter class that wraps a Tomcat
Realm object and plugs it into securityfilter. Since all this work is
done within the webapp (and not in the container), catalina.jar and
friends need to be in the webapp's lib directory. This means that the
Tomcat internal classes (in the webapp) are separate from those loaded
by the system/server ClassLoader, so many things are null or not
available. As I mentioned, this used to work before the Realm objects
became more dependent on lots of infrastructure objects in the running
server.
Does that clear things up a bit?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmLdNwACgkQ9CaO5/Lv0PCKigCgo0atqiLoFv7lb8Pu9SRWM5hQ
UIUAn0lRPmOpLtRkgy11Dgjii1dGH8wP
=YrTu
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: RealmBase's 'Container' requirement (revisited)
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: RealmBase's 'Container' requirement (revisited)
> Should I continue down this road of trying to prop-up a
> Tomcat skeleton server inside the webapp's space
I'm confused (seems to be happening a lot lately): Tomcat already supports context-specific <Realm> usage, so what is the real capability you're providing? Would JMX allow you to create (and destroy) a context-specific Realm on the fly?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org