> 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.
It's more nuanced than that. CAS-1071 identified that Ant patterns cannot be used to define catch-all registrations, and it is that use case exclusively that is not supported. The problem is that many deployers, including myself, were under the mistaken impression that catch-all expressions were supported and are now faced with arguably insecure deployments. > Folks on 3.4.x should be notified of the vulnerability and take > appropriate measures now (i.e. don't use wild card URLs). There is no workaround or mitigation in this advice. For CAS deployments that allow hundreds of services via catch-all registrations, this is at best a herculean task and simply unfeasible at greater scale. Perhaps there are few deployers in this situation, but I am certain they exist, and for them the best solution is a maintenance release that has regex support. And that means supporting both Ant patterns _and_ regular expressions to balance the expected compatibility of a point release with vital new functionality. > Supporting both RegEx and Ant in the way that has been described > requires more work ... but I'm willing to live with it. There's consensus, then, on supporting both. I'm for it, Scott's for it, and you can live with it. Beautiful. Also note that we can drop Ant patterns in a future release if most deployers use regular expressions exclusively at that time. > it's incumbent on > the folks who like to do more to either commit to doing more or allow > the other strategy to proceed. I'll have a pull for review by COB tomorrow. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
