FreeBSD Programming Primer – Part 9

}

October 31, 2013

In the ninth part of our series on programming, we will add some security to our CMS and refine our interface for adding content.

In part 8 of the series, we created the PHP script amendcontentpage.php which allowed the user to add data to any table in the CMS (Figure 1 & 2). We will refine this page, and add a login page and the corresponding database table. Create a login table in MySQL to hold the user credentials (Listing 1).

We require a blob field as we will be storing binary rather than string data for the encrypted password. The auth field will be used to define the user rights later on, but for the moment setting a value of 1 via the form we will construct will be sufficient.

Now add the following to our global.css file to format the output from our amendcontent.php page (Listing 2).
Create a file in the includes directory called login.inc (Listing 3). This holds the name and secret key for the login cookie.

Create a new file login.php in the root directory of the application (Listing 4). Finally, amend amendcontent.php as follows. As there are a lot of changes throughout the file, the script is detailed here in its entirety (Listing 5).

Hopefully, most of the code should be self explanatory, but here is a breakdown of the major functionality of each page.

Login.php

As we are storing the hashed value of the password in the database, rather than a text string that we can compare, we need to initially seed the database with a valid username and password the first time login.php is run.  Once the login table is updated, the call to createnewlogin() can be removed. The page control logic branches depending on the action we want to achieve, and the corresponding function calls either build an HTML form, query the database or add a user to the database.

Amendcontent.php

Most of the action takes place within build_page_2. In the previous version, we could not select any previously entered content so to add this functionality we have added an intermediate step which displays all the content available to be edited. Once the user selects the table record to be amended, this is fed back into our original form, which is essentially identical whether we are updating or adding content. Some “bells and whistles” are added in the form of zebra striping of the table rows, and the automatic generation of the titles. As the script is referring directly to the database, we need a conditional branch at line 266 as the menu table has a different schema from the pages, news and FAQ content.

Getting it to work

Visit the login item via the menu and create a new user and password with an auth level of 1. Check the user has been added to the login table and remove the 3 lines from the start of login.php as commented. Revisit login.php, login and proceed to edit your content as desired (Figure 3-12).

Further tuning
The security is poor – we can have multiple users with the same name and password. A better form of encryption other than hashing is desirable, and we are missing lots of backlinks etc. We should also refactor the code e.g. the license and footers.
In the next part We will address these issues and more.

About the Author

Rob Somerville has been passionate about technology since his early teens. A keen advocate of open systems since the mid-eighties, he has worked in many corporate sectors including finance, automotive, airlines, government and media in a variety of roles from technical support, system administrator, developer, systems integrator and IT manager.  He has moved on from CP/M and nixie tubes but keeps a soldering iron handy just in case.

This article was re-published with the permission of BSD Magazine.  To Learn More about iXsystem’s commitment to open source check us out here:   https://www.ixsystems.com/about-ix/

Join iX Newsletter

iXsystems values privacy for all visitors. Learn more about how we use cookies and how you can control them by reading our Privacy Policy.
π