[Building Sakai] CAS and other filter configuration for login tool

[John Bush]

ok see, SAK-23187.  There is probably a little work to do to get it to
cleanly apply, which I don't mind doing.  Also, we'd want to talk
about how to deal with dependencies.  For example, here at rSmart we
include the cas and shib dependencies by default.  That way for any
client that uses those mechanisms the jars are already there, we just
do some config and move on.

Probably folks have different dependencies that might need to go in
the login tool, in which case a maven profile switch or other
deployment strategy would be needed.

Also in regards to Aaron's comment.  In a way, what I have here is
very similar to what Ray (I think it was Ray) did with the
sakai-configuration.xml work.  The difference is that solution is
applied to the component contexts of our big Spring tree.  This stuff
works at the webapp level.  I'm pretty sure, but never tried it, that
stuff can't override things at the webapp level.  I went back and
forth thinking this could be generic to any webapp, but then ended up
just putting it into login (it could be moved), because I couldn't
come up with another use case where you really need to modify filters
or other things in the webapp context.

The thing that sorta blows is that Spring's context loader really
wants an applicationContext.xml.  If it doesn't find one, it gets very
unhappy.  I actually solved that by having to wrap the ServletContext
to deal with it, that is how intern connected the Spring startup is
with the servletContext.  I ended pulling that stuff out, because it
felt like a big hack, but it did work.  It just felt like maybe I was
overengineering something that really isn't necessary at the end of
the day.  But it sure was a fun trip down into the guts of Spring,
brings back some memories.

On Wed, Jan 30, 2013 at 12:01 PM, John Bush <john.bush at rsmart.com> wrote:
> Steve, yeah, that is what we've been doing for the last couple of
> years as well, which was definitely a step forward.  At this point, we
> are really trying to get to one binary distribution, so the build
> switches cause some issue, because it creates more tags, more config,
> more builds, more chance for error, more things to transfer around
> networks, etc.
>
>
>
> On Wed, Jan 30, 2013 at 11:39 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>> Definitely interested. I did something similar but with filtering where the props get injected at build time:
>>
>> https://source.sakaiproject.org/svn//msub/anu.edu.au/services/2.8.x/anu-conf/sample.build.properties
>> https://source.sakaiproject.org/svn//msub/anu.edu.au/services/2.8.x/login/login-tool/tool/pom.xml
>> https://source.sakaiproject.org/svn//msub/anu.edu.au/services/2.8.x/login/login-tool/tool/src/webapp/WEB-INF/web.xml
>>
>> Same method that is used for the uPortal build filtering.
>>
>> This would be good to have in trunk by default so it works for everyone, using CAS or not, and you just configure it as you please.
>>
>> cheers,
>> Steve
>>
>> On 31/01/2013, at 4:58 AM, John Bush <john.bush at rsmart.com> wrote:
>>
>>> I did some work yesterday that I'm not sure anyone else cares about.
>>> But if someone is interested let me know and I'll submit a jira/patch.
>>>
>>> We had a long standing issue of configuring CAS/Shib and other signon
>>> mechanisms that require servlet filters.  The issue is that you have
>>> to modify web.xml's to configure these things.  That mucks up our
>>> whole binary deployment model, and leads to a bunch of annoying
>>> practices for managing those changes.
>>>
>>> So what I did was create a way to drop a spring config file in
>>> sakai.home that wires up your filters with their configuration.  I
>>> built on Spring's DelegatingFilterProxy and ContextLoader to do this
>>> in a way that works if you have this file in your sakai.home folder or
>>> not.
>>>
>>> Like I said if this has value to anyone else let me know.
>>> --
>>> John Bush
>>> 602-490-0470
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>
>
>
> --
> John Bush
> 602-490-0470



-- 
John Bush
602-490-0470