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 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
