So we all agree that the Ant-pattern approach for Service URL matching is not working in the way that it is intended and likely deployed. Preserving it in 3.5 just doesn't make any sense to me, especially given that the release strategy dictates that deployers can expect some amount of upgrade pain. Getting Service URL matching that works is worth the trouble of having to migrate to RegEx.
Folks on 3.4.x should be notified of the vulnerability and take appropriate measures now (i.e. don't use wild card URLs). I'd also suggest that this could be the workaround until they move to 3.5 with RegEx support, and thus mitigating the need to cut a 3.4.12. This approach is supported by the work that is already completed by Misagh and is my preferred path. Supporting both RegEx and Ant in the way that has been described requires more work and is a step backwards for the project in my opinion, but I'm willing to live with it. However, it's incumbent on the folks who like to do more to either commit to doing more or allow the other strategy to proceed. Either way this should be resolved before we cut RC1, ideally next Tuesday 3/20. I'm +1 for Misagh's commit for 3.5 (i.e. drop Ant for RegEx). -0 for the alternative RegEx/Ant proposal, assuming someone is going to step up to do that work. Bill On Thu, Mar 15, 2012 at 1:13 PM, Marvin S. Addison <[email protected]> wrote: >> It helps support an extremely useful Services Management use case of a >> more general catch-all service versus having more specific catch-alls for >> each sub-domain you care about. > > > This is a _vital_ use case for us. > > >> Ant-patterns do not unfortunately support >> that use case, which can lead to mismatched URLs during ticket generation >> if someone attempts to execute such a use case. > > > *shiver* > I hope everyone that's using catch-all registrations understands the > implications of this statement. > > >> I have expressed some reservations about an upgrade path for existing >> deployers if we were to just turn off Ant-pattern matching and turn on >> RegEx support. I'm starting this thread because I feel we can quickly >> close the loop on that. > > > The beauty of a backward-compatible solution is that it would be feature > compatible with a 3.4.12 release. The functionality that regular > expressions provide are vital for us, so time to release is paramount. > Additionally, for folks that might want to deploy a solution for security > reasons in an existing 3.4.x environment, it would be much faster to QA a > 3.4.12 than 3.5. > > >> Since we expect all Regular Expressions to start with ^ in order to >> support >> matching from the beginning, if the internal software detects that "^", it >> considers that we're using a regular expression. If it does not detect >> that, it assumes you're providing an Ant Pattern match. > > > Sounds reasonable to me. Unless someone has a better proposal, I'm a strong > +1 to go with this approach, get a working patch with reasonable review, and > pull it into master with a subsequent short turnaround for a 3.4.12 release. > > > M > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
