Any caveats for logging into text file?

[F-3000]

I'm wondering is there anything specific I should take into account when writing CMS logging (debug/alerts) into a plain text file? To specify more what I have in mind, think of logging into SQL database, and how stuff need to be escaped to be sure there won't be injection-attack thru log-mechanisms.

In my personal project, there's logging into MySQL database, but I've left out plenty of (perhaps) useful data to minimize possibilities for security-holes, as I'm not entirely convinced that mysqli_real_escape_string() is "do it all"-solution. It's flawed too, so there's need for rewrite anyways. If it wouldn't be my CMS, I would find it extremely hilarious to read a log notation that user had no connection to database (probably a spider-flood).

[broj1]

Writing into a text file could be problematic if you have more than one concurent writing attempt (e.g. two users trigger an error at the same time). With database logging the DB server takes care of queing writes. Also the contents of text files tends to be more clumsy to review, filter or sort. Also when text files grow in size significantly, writing and reading might get slower. I use text files for logging only DB connection errors (where logging into DB would not work).

I think mysqli_real_escape_string function does it's job (which is escaping) but escaping is often not enough. So use other techniques like whitelisting (or blacklisting), string lenght checking etc.

[diafol]

mysqli_res shouldn't be necessary with parameterised queries.

[pritaeas]

If you really want (text) logging (at some point), I can recommend log4php.

[Joel100]

I think it depends on what you are trying to accomplish and what type of data it is. Getting logs from some things are much more difficult than others and you will have varying degrees of success trying to roll your own.

For example, application logs should really come out of the application's logging frameworks so that more details can be caught like errors, context variables, web request info and more. Most of this data is never found in a simple text file being logged to disk.

Most commercial log management products don't even do a good job of tracking application errors to uniquely identify them so they can be tracked and resolved. Stackify (http://stackify.com) is the only product I know of that does this while at the same time doing log management. They are usually separate tools.

Getting app logs from apps that consonantly deploy to new servers or scale up and down creates unique challenges as well.

Getting logs from something like AWS Cloudtrail, Heroku drains, Azure operational logs, etc, etc all have unique challenges that may be difficult if you are rolling your own.

SaaS based log management solutions have also become very reasonable in price. Hard to justify spending a lot of man hours and server costs rolling your own unless you potentially have multiple terrabytes of logs every month.