Peter Cooper wrote: >I recently came across this - very small no of users on an internal >intranet with csp. >typically they log on and stay on all day - 8 hour session timeout > >Buy exactly the license count that matches the number of users
If you don't require #server functionality, I'd personally set the timeout to an absolute minimum, and save the session data somewhere safe on session timeout (stored with the session ID). You can then automatically log the user back on if a timed-out session reappears (restoring the session data to %session). This could prevent a lot of licensing issues, and doesn't require too much code. (This doesn't work if you need #server, because AFAIK you can't automatically re-create a timed-out session from a #server call.) This of course does, in itself, nothing to help when a browser crash occurs or a new browser is opened, but the small timeout limits license exhaustion. Worst case scenario they'd have to wait five to ten minutes before their license is deallocated. >make the logon-screen a non-csp app (asp,perl whetever), the >username/pasword is checked via a Cache Factory or ODBC stored >procedure call Wouldn't the factory and the ODBC connections require a license as well? If so, this still doesn't help. In the situation you describe, you can also do some trickery by sharing a single license among more than one user [1], to make sure you keep one free for the login process. This way, you can have 8 users online and still keep room for a ninth user (that actually is one of those eight) to log on. [1] This may sound like a breach of license terms, but it isn't. ISC doesn't provide for situations as you describe. You only have eight users, yet you can't give the users the twelve connections each they are entitled to, because you can't, AFAIK, have a license-free "identify yourself please" login screen. Note that having a way to login license-free would also prevent the other problem you described, a DOS attack. Gertjan. -- Gertjan Klein
