> Yes, dare I say this could be another block/service to configure and
> load within the Avalon-framework... something like a hack detection
> system.
Sounds like an excellent idea.
> would admins want to change the security restrictions on a per service
> basis
Can you give a use case?
> - would we want to "share" hack information across services, so if
> someone tried to login repeatedly via POP3, we would then forbid them
> from SMTP as well?
Would this also be something where if you DID authenticate with a service,
you might (optionally) automatically gain access to another? For example,
if you successfully access POP3, we'll allow you to use SMTP for X minutes
thereafter?
> time, ip, and account
Time, IP, acount (== user?), authenticate/failure state, attempt count,
service, ... does anyone spot anything else?
> you need to be able to count records from either an ip or
> account perspective, and you need to gradually expunge the
> attempts after some timeout period passes. I could do this
> easily with a database, but I can't think of a good
> in-memory model
I think that perhaps you answered your own question. Why not ask the
Phoenix folks about an (in-memory) database block? AvalonDB is apparently
NQRFPT, but HSQL is present, and might be a good option. Thoughts?
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
