Andrew, Isn't theme one of the items in the RegisteredService now?
Cheers, Scott On Tue, May 19, 2009 at 8:08 AM, Andrew Feller <afel...@lsu.edu> wrote: > Scott, > > Remove Unique User Identifiers: > > GREAT! > > > Separate UI-Related items: > > Sounds good > > > Define acceptable Service URLs: > > Are you saying that there would be a list of accepted protocols (http(s), > smtp(s), imap(s), etc) as a separate feature from accepted service URLs in > the service manager? > > If YES, then GREAT! > > Would it also be possible to include theme_name as part of registered > service? =D > > > Thanks Scott, > Andy > > > On 5/18/09 10:33 PM, "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: > 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
