Things On Demand is set to re open October 2018. The wide-format and 3d printers are being warmed up and put thru their paces in preperation for production runs.

I did a remake of my older design of a Bic Table Lighter Holder and put it up on Etsy for some feedback. Check it out below:

Needed a part to fix the toilet so I opened up Tinkercad and designed a Flush Arm Catch and printed it along with a new Toilet handle and arm.

Done!

7.2.9 is in testing with PHP-FPM, built from source.

Not many changes needed to get it running thankfully.

I'll continue to optimize and build some packages for safe keeping.

While deciding on a code direction for FFS I have decided to do some summer updates to prepare for the fall/winter.

I am officially planning on moving to PHP 7.2.9 server wide. This means checking the code base for any depreciated functions and improving/replacing old functions with new improved ones. This means Sodium crypto over mcrypt, no each() statements, and a slew of other changes. Fun!

Once the above is finalized I will create another VPS *strictly* for production hosting using the best security options from my current setup.

Over on my workstation side since my CPU and mobo support VT-d and I have a spare Nvidia card lying around; I am installing debian 9 (stretch) and planning GPU-passthru for virturalization for those must have Windows 3d apps. Also Fun!

This is going to be an interesting trip...

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).