View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
5815 | Composr | core | public | 2024-07-29 20:37 | 2024-07-29 21:51 |
Reporter | PDStig | Assigned To | Guest | ||
Priority | high | Severity | feature | ||
Status | new | Resolution | open | ||
Summary | 5815: Reduce disk checks for error log | ||||
Description | Currently Composr has to do a disk check on every page load to ensure errorlog.php has a return line. This is problematic for performance. Actually ideally we would not host any logs in the webroot, but that goes against our target demographics regarding users and their expertise with server administration. Work in an alternate solution. | ||||
Additional Information | Slight increase in performance due to the elimination of an often-unnecessary disk check on every page load. | ||||
Tags | Roadmap: Over the horizon, Type: Performance | ||||
Attach Tags | |||||
Time estimation (hours) | |||||
Sponsorship open | |||||
|
Automated message: This issue was created using the Report Issue Wizard on the Composr homesite. |
|
We cannot just rename errorlog.php to errorlog.log and have access controls. It is possible the controls in htaccess and web.config may get disabled or never exist (especially with shady web hosts). A possible solution is to make a new _config.php directive defining the filename. By default, it is a randomly-generated crypto-hash upon installation. That way we can use the .log extension with a reasonable amount of confidence that no spider or human will guess what it is and access it. Then upon this process, we will no-longer need to access the error log on every page load to check for return. Another potential solution is only to check the error log just before we plan to write to it. The return statement would therefore always be in there when something gets written to the log unless someone physically removes that line (and only until something else gets written). |
|
"Another potential solution is only to check the error log just before we plan to write to it. The return statement would therefore always be in there when something gets written to the log unless someone physically removes that line (and only until something else gets written)." We don't do that due to the possibility of it PHP creating the log, and somehow injecting PHP code into the error messages PHP itself generates. |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-07-29 20:37 | PDStig | Tag Attached: Roadmap: Over the horizon | |
2024-07-29 20:37 | PDStig | Tag Attached: Type: Performance | |
2024-07-29 20:39 | PDStig | Note Added: 0008993 | |
2024-07-29 20:41 | PDStig | Note Edited: 0008993 | |
2024-07-29 20:41 | PDStig | Note Edited: 0008993 | |
2024-07-29 21:51 | Chris Graham | Note Added: 0008994 |