In CAS4 I'm looking to be able to support multiple types of pattern matching. We chose Ant Path matching for CAS3 because in general, there's less chance of a syntax error, especially compared to writing regular expressions in Java ;-)
Cheers, Scott On Tue, May 19, 2009 at 2:59 AM, Shivani Chandna <shivani.chan...@gmail.com>wrote: > One comment for :*Request for Comment* - Define Acceptable Service Urls > In our organization we needed the regex pattern matcher to be used instead > of the default AntPathMatcher. > http://www.nabble.com/URL-pattern-matching-of-service-ids-td20486097.html > > This would enable different set of rules to be applicable - starting from > protocol/port/domain...etc. > This can be used both for validation of URL's for service as well as for > Service Management Tool. > > Regards, > Shivani. > > On Tue, May 19, 2009 at 9:03 AM, Scott Battaglia < > scott.battag...@gmail.com> wrote: > >> All, >> >> I've been working on some stuff lately with CAS and based on that I've >> noticed some things that we may wish to change or formalize. I'm placing >> them below as a Request for Comment. I've described them below briefly to >> obtain some feedback. Based on the feedback, we can write a more detailed >> RFC in the wiki for the ones that seem good. >> >> *Request for Comment* - Remove Unique User Identifiers from Service Urls >> >> Currently, in CAS3, we remove the unique sessions identifiers associated >> with a Servlet session (i.e. jsession) from the Service Urls. However, this >> is not a formal part of the CAS specification, but is essential for >> validation to work. Therefore, I recommend that we amend the protocol to >> state that session identifiers (i.e. for PHP, Java, etc.) are removed when >> comparing service urls. >> -------- >> >> *Request for Comment* - Separate UI-Related Items from Interaction >> Portions of Specification >> >> Currently, the CAS Protocol specification details some aspects of the >> protocol that go beyond interaction between the server, the user, and the >> client. Examples include the suggested name of the session cookie, and the >> Warn UI feature. While important, and useful, these details may not belong >> in the protocol specification. >> >> For example, in CAS4 we'll be supporting multiple protocols, and it may >> not make sense to call the session cookie TGC (which is CAS specific), or we >> may have an alternate UI that does not need warn. >> -------- >> >> *Request for Comment* - Define Acceptable Service Urls >> >> Currently, CAS accepts any arbitrary service urls, unless restricted by >> the Services Management Tool (which its recommend you use). This may not be >> ideal, often does not make it clear what services are being accessed, and >> makes debugging harder. >> >> The following prefixes are recommended: >> https:// (or http://) - HTTP based services, including RESTful and SOAP >> based services offered over HTTP >> imap:// (or imaps://) - IMAP services that are generally used for proxying >> smtp:// (or smtp://) for SMTP services >> [Please feel free to add other suggestions to the list of prefixes] >> >> CAS would parse and understand these prefixes only. >> >> Feedback, comments, additional requests for comment are always appreciated >> ;-) >> >> Cheers, >> Scott >> >> -Scott Battaglia >> PGP Public Key Id: 0x383733AA >> LinkedIn: http://www.linkedin.com/in/scottbattaglia >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> shivani.chan...@gmail.com >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- 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
