[cas-dev] easier configuration in CAS 3.1.2-SNAPSHOT
Smith, Matt
matt.smith at uconn.edu
Wed Jan 30 14:58:49 EST 2008
My $0.02 -- I think this change is *fantastic*. This will eliminate the
few issues I have remaining with the maven war-overlay method, if a few
cases are handled:
* A malformed XML file (schema validation, mismatched tags) is
identified by name, and flagged as an ERROR
* XML content that overrides content set by a previously loaded XML file
should be identified by both file names and XML path, and flagged as a
WARN.
This should also dramatically improve upgradeability. If each smaller
config file represents a specific set of functionality, then I only have
to update my overlay war with the files that need to change. Currently,
things like deployerConfigContext are 95% reproduction of the default.
I do not see any increased security exposure either -- as long as no
PATHs or CLASSPATHs are searched, and no dynamic reload is allowed. By
dynamic reload -- can someone add/replace an XML file post-deploy, and
have it automatically loaded and acted on by the server?
Just my $0.02,
-Matt
On Wed, 2008-01-30 at 14:44 -0500, Scott Battaglia wrote:
> How would one get maliciously placed there? When? In the CVS tree?
> Someone could maliciously add it to the list of files in the web.xml
> also if they have access to the source tree. They could also just
> modify the original context files without even adding any new ones.
>
> All this does is eliminate the need to register the file explicitly
> within the web.xml. The web.xml has a specific configuration
> convention --anything that you've put in the specific protected
> directory (its not visible as its under WEB-INF). It doesn't protect
> against malicious attempts any more or less than the original method,
> it just eliminates one more file that needs to be modified.
>
> In fact, it could make it more secure. You're including the CAS war
> from a well known source (the JASIG repository) and your Maven2 WAR
> overlay clearly shows which are new files and which are modified files
> without having to see any of the files you're not touching (so its
> easier to identify them).
>
> Minimizing the number of files that you've modified also makes
> upgrading easier, meaning you're less likely to miss a new
> configuration item (or have to manually merge changes).
>
> -Scott
>
>
>
> On Jan 30, 2008 2:36 PM, William G. Thompson, Jr. <wgthom at rutgers.edu>
> wrote:
> Are you concerned at all that either maliciously or by mistake
> a file
> gets loaded that should not?
>
> Bill
>
>
> On Jan 30, 2008 2:29 PM, Scott Battaglia
> <scott.battaglia at gmail.com> wrote:
> > The XML configuration files have to be placed in a specific
> directory that
> > is under the WEB-INF directory. The web.xml is configured
> to only load XML
> > files in that specific directory. It eliminates the need
> for every deployer
> > to modify the web.xml. It also allows us to break out the
> configuration
> > files into smaller subsets and allow you to override
> specific ones without
> > having to make a copy of the larger file (i.e.
> applicationContext.xml).
> >
> > -Scott
> >
> >
> >
> > On Jan 30, 2008 2:22 PM, William G. Thompson, Jr.
> <wgthom at rutgers.edu>
> > wrote:
> > > Not sure how I feel about loading *.xml files...seems like
> it could
> > > lead to some unintended consequences. Isn't it better,
> safer maybe,
> > > to have these explicitly identified? I'm curious how
> others feel
> > > about this change.
> > >
> > > Bill
> > >
> > >
> > >
> > >
> > >
> > > On Jan 30, 2008 11:56 AM, Scott Battaglia
> <scott.battaglia at gmail.com>
> > wrote:
> > > > For the first time in a long time, I've actually had to
> do a deployment
> > of
> > > > CAS from scratch (shocking, yes, I know). So its the
> first time I've
> > had
> > > > the pleasure of using the WAR overlay method of keeping
> track of your
> > > > customizations. [side note, if you're not using it I
> recommend it].
> > > >
> > > > However, when using it I noticed a few things that could
> be done more
> > > > easily, so I've made a few modifications to the way we
> handle
> > configuration
> > > > files:
> > > >
> > > > Except for the files that we reference constantly or
> need to be in a
> > > > particular spot (I'm looking at you,
> deployerConfigContext.xml and
> > > > cas-servlet.xml), all other Spring XML configuration
> files are either
> > > > located in WEB-INF/spring-configuration/ or
> > WEB-INF/unused-configuration/
> > > >
> > > > The web.xml is set up to load deployerConfigContext.xml
> and
> > > > WEB-INF/spring-configuration/*.xml. You need to add a
> configuration
> > file or
> > > > enable one? Just put it in that directory (preferably
> using the WAR
> > overlay
> > > > method). Some of the things that are more frequently
> modified have been
> > > > broken out into their own configuration files.
> > > >
> > > > This is going in for the CAS 3.1.2 release. If you have
> any suggestions
> > on
> > > > breaking up the configuration files some more, etc.
> please let me know
> > > > within the next day or two.
> > > >
> > > > Thanks
> > > > -Scott
> > > >
> > > > --
> > > > -Scott Battaglia
> > > > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> > > > _______________________________________________
> > > > cas-dev mailing list
> > > > cas-dev at tp.its.yale.edu
> > > > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> > > >
> > > >
> > > _______________________________________________
> > > cas-dev mailing list
> > > cas-dev at tp.its.yale.edu
> > > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> > >
> >
> >
> >
> > --
> >
> >
> > -Scott Battaglia
> >
> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >
> >
>
>
>
>
> --
> William G. Thompson, Jr.
> Associate Director - Architecture & Engineering
> Enterprise Systems and Services, Rutgers University
> voice: 732 445-5428 | fax: 732 445-5493 | wgthom at rutgers.edu
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
>
>
> --
> -Scott Battaglia
>
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
--
Matt Smith
matt.smith at uconn.edu
University Information Technology Services (UITS)
University of Connecticut
PGP Key ID: 0xE9C5244E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080130/bc90cd34/attachment.bin
More information about the cas-dev
mailing list