For the time being I'm going to skip digging into the cache and hope that the default values are enough to get me up and running (I'm sure they are) and move directly along to the database configuration. I will not be returning to the installation page to check out the web configuration notes since I'm already familiar with this and won't be fussing with it now, mod_rewrite works on my server and if it all breaks when I migrate I'll have a clue why.
I'm using a mySQL database for no reason other than that's what I'm most familiar with at present and I know it's well supported by my hosting company. I know there is some debate (read: holy wars) about which is the best to use but I'm going to recuse myself from that conversation right here. Since local database access is available on my server, I went ahead and continued to use localhost through XAMPP. This will, of course, require a migration later from this database to the live server but that's fine.
I had previously worked up a schema and went ahead and implemented it on my host along with the reader, writer and admin accounts I wish to have. I understand I don't need this to be complete in order to get things up and running but having prepared a design there's no reason not to put in as much as I can as I go.
Implementing the read and write connections in mySql is very simple, and the database documentation provides an example of how this is set up under the heading Read & Write Connections. There is no documentation on how to do the different read/write sections with the .env file but looking at the existing keys I created a few like DB_READUSER and DB_WRITEUSER, passwords etc in .env and modified database.php so the end result looks something like this:
'connections' => [For those unfamiliar with utf8mb4_unicode_ci as I was it's an extension of utf8 to allow it to be expanded to 4 bytes for new code pages like Chinese and emoticons. The _ci has a more correct lexicographical sorting order than then _bin version with a minor trade off in performance.
'mysql' => [
'read' => [
'username' => env('DB_READUSER', ''),
'password' => env('DB_READPASS', ''),
],
'write' => [
'username' => env('DB_WRITEUSER', ''),
'password' => env('DB_WRITEPASS', ''),
],
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', ''),
'unix_socket' => env('DB_SOCKET', ''),
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
]
],
The rest of the instructions on the documentation page begin to delve into use of the database, which I'm going to gloss over for now. On to sessions.
The first choice is which driver to use. A little bit of research suggests that for smallish sites file or database are quite good enough solutions and a little more reading suggests file for low latency and reduced SQL traffic overhead. I'm unlikely to run out of storage space due to the session files and I'm only running on a single server, so "file" it is. Just a reminder that while I'm looking at my session.php I'm making most of my edits in the .env file.
Scanning the file I see the server side encrypt option is false by default, which strikes me as a little odd since of course security is a big topic. I can see the justification here for performance ... as long as the server itself is secure then there's no worry on the session files. I may revisit this information if I start collecting any sort of sensitive information like credit card numbers, etc, some experimentation on the performance hit will be in order. For now it's on the "to do" list to look into this more later.
A small thought towards security, if you're particularly bent this way, is to change the session storage location from the default value. My thought is that if the server is compromised then so are the config files, so in this case I won't bother.
The next setting I want to look at is "secure" ... I have a temptation to set this to true because my app will only communicate on https, with requests for http being redirected to https. I see that there's an issue with setting secure "remember me" cookies. I think I want to change this to true, but for now while I'm testing locally on http I'll leave this as false. I'm making a note to review this decision later in the development. With password managers and such being increasingly used in browsers I need to think about this some more.
There are clearly a lot more settings to dive into but for the moment I'm going to leave them alone. I'm feeling sufficiently configured to actually start working on the app itself!
No comments:
Post a Comment