Documentation

Overview


About this Demo

You can't actually modify the stuff under the "Developer" heading. You can delete exactly one user record, that being your own. Registering an account to test the login stuff created the record, and you can delete it and clean up your tracks. Only session data is stored, and that is cleared out regularly.

Core is a skeleton web application, used for rapid application development. It provides a minimal set of facilities for a basic web application. That said, any website built on Core alone is probably overkill. By that I mean that Core doesn't add much to a simple website, consisting of a handful of static pages, except unnecessary overhead. There is little value in Core, apart from the ability to quickly extend it to build something more useful and gutsy, like a bespoke application for a small business or organization, or perhaps a prototype for a more ambitious application.

What the documentation pages lack in specificity is probably to be found in the inline documentation. Practically every form control element has an inline tooltip explaining its name, data type, and purpose.

What Core Does


User Authentication

Core provides a system for authenticating users, and by default allows visitors to self-register an account with nothing more than a username and a working email address. Core extends CakePHP's own authentication system.

After submitting their chosen username and email address, a secret login code is generated and sent to the email the user just provided. The user must retrieve that login code from their email, and then use it along with their email address to log in. Thereafter, any time a user wishes to log in to the system, they must first request a new login code from the application.

Users never have to worry about their passwords being compromised, and website owners never have to worry about users having crappy passwords. Login codes are generated on demand, and have a one hour life span, before they are rendered useless. Also, when a user logs on using a login code, that code is automatically rendered useless, too.


User Authorization

Out of the box, Core has a default authorization scheme, and it is dead simple to understand and to use, and it's up to the developer to examine the basic "truth table" format implemented in the custom configuration file (/config/core.php) and decide whether that will be sufficient for their own purposes. The default permissions, roles, and controllers/actions are defined in the configuration, but the code required to parse this data per request is found in each controller, similar to the authentication component.


User Management

Core provides basic user management via database operations, like Create, Read, Update, and Delete, otherwise known as "CRUD" operations. Users can be manually added, and they can be modified so as to allow or disallow them to log in, individually.


Timezone

Best practice is to store date and time values in UTC, and then to display them in the user's own timezone format, and so Core allows a user to choose their preferred timezone, and this is stored in the database and set in the session data.


Login Devices

Users may optionally register their phones or tablets by entering the mobile number for their device and choosing their mobile service carrier. When ever a user requests a login code, the code is automatically sent to their email, and it is also sent to any devices they have registered via SMS, or texting. This way, a user can still log in from their mobile device even if that device does not provide them access to their email.


OpenGraph Tags

OpenGraph tags were pioneered by Facebook, but nowadays, most social media and sharing platforms look for OpenGraph meta tags in a website. These are the tags that provide the site name, a picture, a description, and more that are recognized and used to present the shared link to users. This feature is indispensible, not only because it provides a microformat for helping to promote our application, but also because it is part of the structure of the Semantic Web, an undertaking to make the Web a more universally accessible and comprehensible database of human knowledge.


Everything CakePHP 3 Does

Anyone who is familiar with CakePHP should have no problems understanding most of my code on first sight. A firm foundation in PHP and SQL for MySQL is all that is required, past that, and of course an equally firm foundation in HTML, CSS, and JavaScript. All of the browser code in this application is powered by the Bootstrap and jQuery libraries. The front end example pages and the back end dashboard pages are based on free templates by StartBootstrap.com. This application implements the optional Security and Csrf components included with the CakePHP skeleton application.

What Core Doesn't Do


Collect User Data

No IP addresses are collected or stored, and no data whatsoever is collected by this application, nor is any user data collected in the online demo found at https://core.applebiter.com. That's on purpose. There's nothing stopping you from building an application that collects all teh datas on top of Core, but I ain't doin' it. There is no third-party code, either, such as Google AdSense or statistics or any counters of any kind. No profiling of users individually or in the aggregate is happening, nor will it happen unless agents of the mob or the government literally command, threaten, or cajole me into it. If that happens, I'll just abandon it. So no worries.


Force You to Use HTTPS

Do it anyway. In most shared hosting environments these days, it costs nothing extra to have HTTPS secure hosting. There is literally no point in bothering with passwords, or authentication, or authorization if you aren't using HTTPS. It doesn't solve all of your security concerns, but it is the first place to start. By the way, I lied. The .htaccess file found in the document root does redirect non-secure HTTP requests to secure HTTPS requests, but obviously you could just remove that rule. Don't do that, please.

TODO


  1. The form used to define new login devices has client-side validation with rules that change dynamically, based on the country code associated with the user's chosen timezone. That seems reasonable, but the server-side validation for a new device's number value is statically set to validate for a North American phone number pattern (eg. (123) 456-7890). It would be great to have a dynamic server-side validation do what the client-side validator does. I suspect that CakePHP does have an optional library for this.

  2. Create an interface to make it easier, or perhaps more manageable to modify role-based permissions on a per- controller basis. I think I will move the permissions settings out of the configuration, and put them in a JSON document in the /data folder, and perhaps store the JSON in the database as well.

  3. Follow my own convention of having Core simultaneously store certain data both in the database and in the filesystem, and make it possible to store the Core configuration and the sitewide OpenGraph tags in the database, as they are already stored in the filesystem.

  4. Store all sensitive user data in the database using two-way, public key encryption. This will require a user taxonomy on the filesystem, wherein to store protected files, outside of the document root.