tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric B." <ebe...@hotmail.com>
Subject Re: How to define a Realm as a global resource and use it as a ResourceLink?
Date Sat, 08 Aug 2009 02:47:47 GMT
> "Caldarale, Charles R" <Chuck.Caldarale@unisys.com> wrote in message

> > In order to secure and clean things up a little, I would like to
> > move my JNDIRealm definition to a global resource and use it within
> > my context
>
> Sounds like you're confusing two separate and distinct facilities of 
> Tomcat.
> Any <Realm> is for Tomcat's use only, not for use by the webapp.  Any
> <Resource> is for the webapp's use, although Tomcat may manage 
> appropriately
> configured ones on behalf of the webapp.
>
> If this particular <Realm> controls access only to this one webapp, then
> its proper location is within the <Context> element of that webapp.  Any
> wider scope (such as <Host>) will cause the <Realm> to be used for all
> webapps of that <Host>.
>
> What do you actually want to achieve?

Well, it was more a question of security, to a certain degree.  If I want to 
make a JNDI resource available only on a per-context basis, but do not want 
the webapp developer to have access to the parameters of the resource, I can 
define a global resource and just link to it in the context.xml file. 
However, I can't do that for the realm.  So either I need to declare the 
realm at a host or engine level which would then apply to all contexts that 
don't override it, or declare it in the webapp context.xml file itself, 
which is accessible (and hence potentially modifiable) by the developers of 
the webapp.

It isn't really a big deal/failure.  It just would have been nice to be able 
to segregate the admin portion of the definition to the declaration.

For instance, with JNDI dbcp resource pools, you can declare the resource 
globally, link to it in the context, and have Tomcat do all the resource 
pooling for you.  I somewhat expected the realms to follow the same 
logic/behaviour.

Thanks,

Eric




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message