resource element
How are resource elements in a context.xml file processed by Tomcat 5.5.x? For instance... Resource name= services/myservice auth= Container type= com.mycom.BasicService factory = com.mycom.BasicServiceFactory / ...I am assuming this would use BasicServiceFactory to create an instance of BasicService and bind it to the appropriate node in JNDI correct? How do I go about passing parameters to the BasicService object? Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Documentation Error
The documentation at http://www.uportal.org/administrators/building.html does not mention the server.home property... Before deploying uPortal you may need to modify the build.properties. Edit the file and find the deploy.home property. ...should read... Before deploying uPortal you may need to modify the build.properties. Edit the file and find the server.home and deploy.home properties. Bernard Durfee - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pluggable mechanism for loading context config files
Mark,
I disagree, I have always felt it would be a good idea to have the
database passwords and such encrypted when in the context files. Those
context files fly all around stuffed in WAR files and stored in CVS
repositories and 'Hey Bob, does this context file look right?'. That's
an awful lot of chances for someone to 'see' a plain-text password,
whether by malicious activity or a simple 'over the shoulder' accidental
glance.
If the password was encrypted using a method where the encrypted string
can only be decrypted by Tomcat using a key stored safely on the Tomcat
server. A key which can sit on the server and does not ever need to
leave the server. The key can be used to encrypt passwords, which can
then be put in the context files. Now the risk of someone 'seeing' the
password in the context file is not as damaging, because the encrypted
password won't be useful. In fact this could be used to encrypt the
password, username, SID, etc. so that these details would be obscured as
the context files go from the developer's workstation to home to their
laptop to the test environment, etc.
This is at best a strategy of obfuscation, but I think it is a worthy
feature.
Bernard Durfee
-Original Message-
From: Mark Thomas [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 06, 2005 5:25 PM
To: Tomcat Developers List
Subject: Re: Pluggable mechanism for loading context config files
Alex,
I would vote '-1' for any such addition Tomcat.
Let me explain why by way of a simple example. Let us assume that Tomcat
requires a plain text user name and password to connect to a database.
First of all, consider the security risks if the information is stored
in an unencrypted file somewhere on the server. Assuming that this file
is not publicaly available, only users with access to the machine can
access the file. With a little more configuration and possibly some
network security only users with physical access to the machine can
access the file and read the password.
If one or more 'untrusted' users has physical access to the machine it
is pretty much game over from a security point of view. With physical
access there are a whole host of potential attacks I can think of that
would enable an attacker to gain access to the file.
Therefore, all we are trying to do is protect the contents of a file
from a group of users all of whom are authorised to see it. What is the
point?
Looking at it from another perspective, lets say we do encrypt the file.
How does Tomcat decrypt it? Tomcat needs access to the decryption key.
If this is in a file, the file needs to be protected. How do you do
this? This is the same problem we had before. We have just added another
layer. It is a chicken and egg situation with no solution. The same
applies to providing the password via some 'service'. How does the
Tomcat process authenticate to this service to retrieve the password? It
needs some credentials. Where are these stored? In a file... and so we
start all over again...
One thing that could work is not placing the password in a file at all
but requiring it to be entered at start up. However, this exchanges a
confidentiality security problem for an availability one - if the system
fails it can only be restarted when there is someone present who knows
the password. Also, people being people, there is a strong chance this
password will get written down and your security has just got worse
rather than better.
Ultimately, the best thing you can do is leave the password unencrypted
in a file and make sure the machine is electronically and physically
secured with the right policies and procedures to ensure that it remains
secure.
Regards,
Mark
Roytman, Alex wrote:
Dear Tomcat developers,
I would like to implement context config file encryption. It is a
pretty useful feature since passwords to various resources are stored
in those files Unfortunately the way how context config files are read
is hard coded (InputSource for Digester is created from
FileInputStream) and does not let me do so.
It would be great if tomcat 5.5 provided some pluggable
ConfigFileLoader in HostConfig (and may be on Engine level as well) to
return InputStream for a given config file name (or decorator for
FileInputStream ). It would be also great if it were possible to
register context config file extensions other then *.xml - it would
allow to use *.exml for encrypted XML config files (will save us a
test of the file to se if it is encrypted or plain text)
If it is not possible to make this enhancement may be you could
re-factor ContextConfig class so it can be effectively subclassed and
its input stream logic altered
All you would need to do is to factor out
protected void processContextConfig(InputStream) {
}
from
protected void processContextConfig(File file) {
if (log.isDebugEnabled())
log.debug(Processing context [ +
Bug Fix - Sort of...
Hello,
This is my first post to the list, so I am not sure of the protocol for
making contributions to the project. I had some problems getting a data
source configured in Tomcat 5. My data source factory was not being
used. After some struggle I found that I needed to put the factory name
as an attribute on the nbsp;Resource element. So the
nbsp;ResourceParams element seems to be ignored.
HOWEVER! In the process of pulling out my hair to figure out what was
going on I 'fixed' the org.apache.naming.factory.ResourceFactory by
refactoring, commenting, and enhancing the exception messages to spit
out some information instead of just a one liner! These modifications
are below. I also added some comments to the code so that future
developers can figure out what the heck is going on. I would love to
contribute this to the project, I've read about 10 other threads on
various web-sites of people frustrated by the lack of error messages
related to this bug.
==
/*
* Copyright 1999,2004 The Apache Software Foundation.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.naming.factory;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.Name;
import javax.naming.NamingException;
import javax.naming.RefAddr;
import javax.naming.Reference;
import javax.naming.spi.ObjectFactory;
/**
* Object factory for Resources.
*
* @author Remy Maucherat
* @version $Revision: 1.3 $ $Date: 2004/02/27 14:58:54 $
*/
public class ResourceFactory implements ObjectFactory {
// ---
Constructors
// --
Constants
private static final String DATASOURCE = javax.sql.DataSource;
private static final String MAIL_SESSION = javax.mail.Session;
private static final String DATASOURCE_FACTORY_PROPERTY =
javax.sql.DataSource.Factory;
private static final String MAIL_SESSION_FACTORY_PROPERTY =
javax.mail.Session.Factory;
private static final String MAIL_SESSION_FACTORY =
org.apache.naming.factory.MailSessionFactory;
// - Instance
Variables
// - Public
Methods
// -- ObjectFactory
Methods
/**
* Creates a new object using the specified factory
*
* ol
* liThe factory class name is determined/li
* ol
* liThe class name is retrieved from the Reference object/li
* liIf the class name is not found, a default factory is
created for the desired object/li
* liIf the class name is still not found, an exception is
thrown/li
* /ol
* /li
* liOnce the factory class name is determined, an instance is
created and used to create the desired object/li
* /ol
*
* @param resourceRefObject The reference object describing the
DataSource
* @param name Passed to factory
* @param nameCtx Passed to factory
* @param environment Passed to factory
* @return The object instance; null if the 'referenceObject'
parameter is not an instance of Reference
* @throws NamingException When the factory could not be created
* @throws Exception When the factory could not create the obect
*/
public Object getObjectInstance(Object referenceObject, Name name,
Context nameCtx, Hashtable environment)
throws Exception {
// Make sure the Reference was passed in
if(!(referenceObject instanceof Reference)) {
return null;
}
// Cast the incoming resource reference
Reference reference = (Reference) referenceObject;
// We need to create the factory class
final Class factoryClass;
// First check to see if a factory name has been supplied with the
reference
RefAddr factoryRefAddr = reference.get(Constants.FACTORY);
if(factoryRefAddr != null) {
// If so, get the classname of the specified factory
String factoryClassName = factoryRefAddr.getContent().toString();
// Get the context class loader; may not be available
ClassLoader tcl = Thread.currentThread().getContextClassLoader();
if(tcl != null) {
// Use the context class loader
try {
factoryClass = tcl.loadClass(factoryClassName);
}
catch(ClassNotFoundException exception) {
NamingException namingException = new NamingException(Could
not load resource factory
