benwillies.com

News

Password Reset Links
 Tuesday, October 25, 2016

A potential security issue has been closed concerning the inadvertent exposure of password reset links to a third-party. You can read about it in an article by Derek Prior at thoughtbot. Since no external content is ever loaded within the framework, this could only be a problem if your framework-based application loaded images into a customized version of the password reset page, or if there were any links on that page pointing to a remote host. Please check-out how the password reset script provides a workaround to the issue using cookies.
PHP 7.0 Compatible
 Tuesday, September 27, 2016

The framework now runs on PHP 7.0.11 but a few minor code changes were required. The first weirdness is that php7 loads via the php5 directory in Apache but still pulls the ini file from php5/lib. Also when storing php sessions in MySQL, session_regenerate_id was issuing an error and execution stopped. The fix was to force the return value of the session handler to be a string (see ivanweiler Dec 17, 2015 comment on GitHub).
Emailing Ad Hoc Reports
 Saturday, March 19, 2016

An Ad Hoc Report can now be emailed to one or more recipients, either as an attachment or embedded as html or both. The report is run when the email is generated so it always reflects the current status of the database. The embedded report and the attached report do not have to be the same report and you can pass parameters that modify the content of either report when calling the send_letter web service.
Distributed Queries
 Saturday, February 27, 2016

You can now run an Ad Hoc Report query in parallel on multiple DB servers and when all the threads have finished processing, the results from each one are consolidated into a single report. The servers are identified as nodes in the configuration file and are selected on the Edit Query page. The author of the report will need to know when enabling a distributed query is a good idea and also which servers to target for the particular query. Typically, in a master-slave environment, you would only run a report on either the master or the slave, not both. However, there may be a process running independently on the master and the slave, perhaps collecting performance statistics unique to that server, so having a single report that gathers data from both servers is very convenient, especially because the queries are run simultaneously with very little overhead. But this feature really shines in highly distributed architectures consisting of cloned servers in multiple data centers. The only caveat is that summary reports will not be fully aggregated across the entire report. Please note that this distributed query feature is fully supported in the reporting api services. In addition, the caller of the run_report service can optionally specify that only one of the nodes will run the query.
Account Lockouts
 Friday, January 8, 2016

The number of failed login attempts that cause the user's account to be locked, along with the time the account will remain locked, are now configurable options. When an account is locked, then no login will be successful, even if the correct credentials are entered. To disable lockouts, comment-out or set to zero the PASSWORD_ATTEMPTS setting. However, locking an account after too many password guesses is an important security consideration and makes it much more difficult for password crackers to break your site. Typically, an account should be locked after 6 failed attempts for 30 minutes. The user will be able to see how much longer they have to wait by clicking the Login button. To lock an account permanently after a number of failed attempts, comment-out or set to zero the PASSWORD_LOCKOUT option. An administrator will then have to manually unlock the account. The user can also unlock their account by resetting their password via an email link.
Idle Timeout and Session Expiration
 Friday, January 8, 2016

A new option for monitoring inactivity of authenticated users has been introduced. If nothing happens on any page of the site, including mouse movement, for a configured time period, a warning will be displayed asking the user whether they want to continue their session. If the user fails to respond after 30 seconds, the session is terminated and the browser redirects to the login page. The default idle timeout setting is 1800 seconds or 30 minutes. Note that if you enable this feature, you should set the SESSION_TIME to a very large number, like 21600 seconds (6 hours), since the idle timeout will expire any abandoned session. To keep the old behavior of expiring sessions after a fixed time interval, comment-out or set to zero the SESSION_IDLE configuration option and lower the SESSION_TIME option to something reasonable, like 7200 seconds (2 hours). Note that php typically expires sessions every 1440 seconds.
 Results 19-24 of 109
Advertisement