What is the use case for throttling the TGT? A client configured confusingly that redirects back to the CAS server requesting a new ticket? A robotic attack?
In either scenario I don't see that it matters whether the ticket is removed or not. On Fri, Aug 5, 2011 at 8:05 AM, William G. Thompson, Jr. <[email protected]>wrote: > 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 > > -- 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
