> Application's main goals > 1. Simple install. > I don't want use cron jobs for cleanup - I think, it can be problem > for some users.
Most of the existing session stuff is written to leave cleanup to you. If you don't want to use cron jobs, you can do it in a cleanup handler, possibly exec'ing a separate script to avoid keeping the heavy mod_perl process around. > I need to authorize user and don't want to query on every request is > you admin, which departments you belong to etc.. Unless you're willing to put real information in the cookie (not just an ID), you have to do some kind of lookup on the server-side for every request if they need session information. It may not be to a database though. If you know that each user will stay on a single server, you can use a disk-based technique like Cache::FileCache or Apache::Session::File. > Apache::AuthCookie doesn't want to set cookie on redirect (see above). There's a lot of stuff in the archives about cookies and redirects. Maybe that will help. You're not the first person to have problems with this. > I don't think that it is good to use the Oracle database for > maintaining state or secrets for tickets. It can be slower than query > indexed table even on every request for password and departments where > user works. It's generally fast enough, since it's a single row retrieved by ID. MySQL is very fast at this kind of thing though. - Perrin
