Being overkill code wise is a thing I have really tried not to do over the years. I literally made a promise to myself a few years back to stop optimizing a codebase until even I'm like WTF was I thinking. Keeping FFS true to being a simple CMS is very hard to do.

The TODO list doesn't show the page to PDF output, login session DB, and about a half dozen other "features" I decided to add in on a whim. While the login session DB I think is a good thing... it definitely sounds like overkill to most I've talked to.

My premise was to only have 1 session variable comprised of the site's secret key intersected with the visitors ip, browser agent string, day of the year, and the actual session ID. This gets written to a sessions DB upon login and wiped after logout. On every script load the "session key" gets re-created and a lookup in the session DB occurs. This gives the script the userid and other vital details needed to create a positive identification of the visitor like ACL, name, email, etc. 

What's funny to me is I started off just trying to load all of a visitors details from the DB at load to decrease DB reads. Barely 1/8 of a kb of memory for each user isn't much of a tradeoff for DB reads I thought. Before this, the script would load the ACL, userid, etc from a session variable which I decided was "insecure" in the end. 

Now, I'm in debate with myself. A sessions DB that is required to login could leave the site open to a much greater surface area of attack during a DDOS. Not like a DDOS would only cripple logins only but I've seen and read about horror stories when PHP is hammered... anything can happen that you wouldn't expect normally. For instance I have a account with beyondsecurity.com to scan this site every week. After it scans I check the logs and its indeed getting hammered by requests. The DB locks up thankfully but this creates a problem for say logging in since the last on table column gets updated at the very least. Trying to write to the sessions DB in this instance would not be possible so an admin could not log in to save their lives.

I think I need a middle ground... write to the sessions DB *if possible*, but don't rely on it if it fails. Do rely on read-only DB reads if possible to allow an admin to login during an attack (or other problem).