[cas-dev] easier configuration in CAS 3.1.2-SNAPSHOT
Scott Battaglia
scott.battaglia at gmail.com
Wed Jan 30 17:04:29 EST 2008
On Jan 30, 2008 2:58 PM, Smith, Matt <matt.smith at uconn.edu> wrote:
> 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
This is definitely flagged (I just tried).
>
>
> * 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.
In Spring, as far as I know you can't really override something (I'd have to
read more). We're overlaying/replacing at build-time.
>
>
> 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.
If you get a minute check out the way its broken out so far in the HEAD and
let me know if you want it broken out even more. I kept
deployerConfigContext.xml as is right now because of the minor release
number. But if we want to do a major change to the config file I can
bump us up to 3.2 (there are enough other changes to warrant 3.2 if it was
required).
Thanks
-Scott
>
>
> 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
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080130/ec3de4d4/attachment.html
More information about the cas-dev
mailing list