Mon, 27 Aug 2018 17:55:26 -0500
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.
PHP 7.2.9 in testing on Archamedis.net
Sun, 26 Aug 2018 18:47:03 -0500
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.
Updates all around
Tue, 21 Aug 2018 01:10:55 -0500
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...
Wed, 15 Aug 2018 21:28:26 -0500
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).
User Registration Enabled
Tue, 07 Aug 2018 19:25:23 -0500
Decided to open up the site to User Registrations after doing yet another code audit. Just click the Register link on the bottom menu. A valid email is only required if you forget your password as that is the only way to reset it.
User mailboxes are being coded now and at first will only allow messages to/from admins. In the future as more social features are added, users will be allowed to message each other with attachments if they opt-in.
Usersites are expected to be added after the mailboxes are fully implemented. Think of them as 1 page sites with file uploads allowed.