Folks, A first pass at TicketGrantingTicketExpirationPolicy and TicketGrantingTicketExpirationPolicyTests is up on https://issues.jasig.org/browse/CAS-1003
The policy implements the sliding and hard timeout as well as the throttling (cool down). However, I think there may be a problem with using isExpired for the throttling feature in a high load environment. If the RegistryCleaner happens to calls isExpired within the cool down period won't that purge an otherwise valid ticket? A cleaner way to implement throttling might be for the CASImpl to check the time between last use. Thoughts? Bill On Thu, Aug 4, 2011 at 11:04 AM, William G. Thompson, Jr. <[email protected]> wrote: > OK. I'm going pursue this today. Should I do that on: > > * > https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2 > (this is where the HEAD of 3.4.x current is, correct?) > * branch from there? > * something else? > > Bill > > > On Thu, Aug 4, 2011 at 10:50 AM, William G. Thompson, Jr. > <[email protected]> wrote: >> On Thu, Aug 4, 2011 at 9:59 AM, Marvin Addison <[email protected]> >> wrote: >>>> I therefore strongly feel the default TGT expiration policy should include >>>> a >>>> hard timeout. CAS adopters should have to customize if they want to opt >>>> out of a hard timeout >>> >>> +1 >>> >>>> It could just be TicketExpirationPolicyImpl, with properties for >>>> * number of allowed uses (-1 means infinite) >>>> * sliding window time length >>>> * fixed window time length >>>> * frequency of use throttle time length >>> >>> With reasonable defaults and the ability to make any of the time spans >>> infinite with a -1 value, I'd be fully behind your proposal to make >>> this the default policy for TGTs. I could go either way on the >>> recommendation to replace existing policies with this one. They're >>> already developed and tested -- why get rid of them? >> >> If they are superseded by the approach, deprecating/removing them >> overtime reduces the code/docs maintenance burden and reduces >> configuration complexity. >> >> >>> >>> On the matter of naming, there's simply no use case for throttling >>> with ST expiration policy since the number of uses should be small >>> enough to prevent abuse. Keeping TGT in the name is one way to >>> indicate this, but I do like the idea of improving the brevity of our >>> component names. >>> >>> --1 for the use of Impl in any component names. Don't even touch that >>> -- it merits it own thread on a slow day. >>> >>> M >>> >>> -- >>> You are currently subscribed to [email protected] as: [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
