> 1. I am interested in implementing Inspektr for auditing. I assume I will > need to manage DB growth outside of CAS. (ie. delete entries after some time > period).
Correct. > And I assume I would need to create my own queries/reports... Correct. > I need to let > the DBAs know how fast this DB will grow with about 30k logins per day. >From some painful experience in this area, it's better to store less and then increment as needed than vice versa. We had to increase our SAN allocation at least twice due to poor capacity planning. In case it helps, we formerly stored 180 days of audit data. Now we store 60 and are much happier. At 180 days, queries take so long as to make it totally unusable. If you're on Oracle you could likely optimize using table spaces (or similar tricks on other platforms), but I'd argue you're better off keeping only as much as required by policy/law. > So if I leave my browser up for more than 5 minutes without logging in I > lose the service parameter and just get the successful log in page. I just verified this with 3.4.9-SNAPSHOT. Here's the exact flow: 1. Hit login form with service param 2. Wait > 5m 3. Submit 4. Blank login form displayed without service param in URL I would imagine this is because the service is stored exclusively in the flow state, when it should be either flow state or request parameters. This would fix the problem since the action of the post includes the service if present. You mentioned this was fixed in an earlier version. I'd recommend that you reopen that issue, or create a new one if you can't find it. > My current > solution of refreshing the cas login page every 5 minutes seems like a real > hack Agreed. I think we should fix the problem, but as a workaround for now, why not simply increase the session-timeout in web.xml to a more liberal value, e.g. 15m? 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-user
