I fully understand. For simplicity of implementation we similarly didn't add any new fields either or UI elements, we just used a longer prefix so we could handle both "regex" and "domain" patterns. In practice we found it was a little tricky to construct a good regex or ant pattern for a domain that you couldn't cheat past. It left too much room for user mistakes, which meant it was probably more secure to let users just enter a domain/subdomain and let the system make sure that the URL passed. Also, we manage a lot of domains, so the "domainlist" option was VERY important. (Writing regular expressions for a long list of domains becomes very unreadable very quickly.)
-Nathan On 8/14/12 9:03 AM, "Marvin Addison" <marvin.addi...@gmail.com> wrote: >> 2) Additional algorithms and greater flexibility for registered service >>URL >> matching. >> Instead of ^(regex), we use various prefixes: >> regex:(regex) >> domain:domain1.com > >Note that the requirement for prefixing a regex with a caret was >entirely for simplicity and backward compatibility. We didn't want to >add any additional fields to the service create/edit form (which would >have required translation effort), so starting with a caret is the >flag to identify the pattern as a regex. Indeed it would be better to >have a radio button for pattern type, but again this requires >internationalization effort. > >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
