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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
