Secure site search

In my last update for Path to 2265, I briefly described the major improvements made to the searching capabilities of the website. Today, I’m going into detail about these changes and why they are important for security and code quality. Examples included!

How it was
The decision to add a search to the website was made fairly early on, during a time where other aspects of the website like the visual layout design were more important to me. This resulted in a crude but working search solution that you can read about here. It is a very linear search in that it just finds and returns the results sequentially in the order they were found by the SQL query. And that was fine back then, but something better is needed now!

I should mention that in November, the search feature got a little attention with the conversion from raw MySQL calls to PHP Data Objects (PDOs) with prepared statements. Whilst this was a major plus for security, the implementation was still ugly and quick.

The new concept
A search that is to be deployed on the WWW needs to be functional AND secure. It is not hard to find reports about SQL injections and other malicious acts against site searches that can be a pain in the butt to deal with. With that in mind, I decided to rebuild the search engine from the ground up with security (and good code quality) in mind. The new concept calls for class encapsulation as well as PDOs – the usage of object orientation allows for controlled access to the code querying the database by only providing a set amount of methods and required arguments to interact with said code.

How does this all benefit security?
Well, PDOs alone do not help much in terms of security. But the usage of prepared statements does by separating the variable part (in our case, the search term) of an SQL query into a method that can safely bind the variable and exclude any nasty code. Here’s a good page about SQL injections and prepared statements!

Class encapsulation also does not actually affect the SQL’s ‘secureness’ directly. But if it is used right, it can provide a reduced interface that could be used for code security purposes (as well the usual benefits of using object-orientated code). If the core code is not in a class, the code will be executed in a procedural manner where there are no barriers to what you can supply that code. But if that core code is in a class, you can then write a select few methods inside that class that can access that encapsulated code with a parameter set that can be as wide or as tight as you want. In my case, I want to tighten how the code is accessed, hence “reduced interface”. All methods that can be called only take in data that I believe is needed for operation and nothing more.

Example – class specification
This is a listing of the class members for an example I will be using to show off these concepts at the basic level. The class structure is based on Path to 2265’s engine – the major difference is the exclusion of the experimental ordered tag search (more about that in a later update) that I am still working on.

  • private $dbHandle
    • stores instance of PDO object with database connection details
  • private $statement
    • stores prepared statements
  • private $query
    • stores last-processed query string
  • public __construct()
    • class constructor
  • private cleanString($string)
    • removes special characters from any input string
    • $string – input string to ‘clean’
  • private processInput($input)
    • breaks down an input string into an array of characters for tag searching
    • $input – input string to break down
  • public createStandardSearch($class, $col, $term)
    • executes a linear search
    • $class – table in the database to search from
    • $col – column in the table to match from
    • $term – input string
  • public createTagSearch($class, $string)
    • executes a basic unordered tag-based search
    • $class – table in the database to search from
    • $string – input string
  • public countResult()
    • returns a count of results matched
  • public getResult()
    • returns result for when a single result is expected
  • public getResults()
    • returns result for when an array of results is expected

Example – implementation
I have uploaded an implementation of that class specification that works almost out of the box (you’ll need to enter your database’s details etc). As I said earlier, it is based on Path to 2265’s code for the same functionality.

Link!

Disclaimer: if there are any errors in that code, I am not liable for any damage they may cause – the code is provided for demonstrative purposes only.

20180103_search
An example of how you could interact with the SearchEngine class from the ‘outside’


Other possible applications this example can do
The great thing about this implementation is the fact that it can be used for things other than just ‘normal’ searching. By using the standard search feature and retrieving a single result, you effectively have the main thing you need for making a dynamic website!

So if your website has something like a database-style section (many in the case of Path to 2265), you can get rid of those countless HTML pages and have a single page instead that calls upon the SearchEngine to find and retrieve the desired page data (indicated with a unique ID through a variable in the URL) in your MySQL database and display the information accordingly.

The best example of this on Path to 2265 is the Database section: clicking on any of the ships (take http://pathto2265.com/resources/apps/ship?ID=2095_ECS_J as an example) takes you to the same page for all of them, expect they all have a different IDs in the URL. A provided ID on that page is fed into the search engine via a standard search call and the single result is fetched and echoed into their destined positions in the markup for you viewing pleasure. It’s great, isn’t it?

Anyway, I think that’s it for today! I hope this has been an interesting read!

Advertisements

Site name simplication, PHP classes, and more

So I’m gonna be shaking up how I do updates for Path to 2265 from now on. Firstly, these updates are going to be more structured because I want to make them easier to read. Secondly, I want to make it so people can either briefly look at the change list or read details depending on what they want to find out. Also I am removing any set times for posting updates since I’ve missed almost all the targets for posting them these last few months. So with out further ado, here’s we go!

Sitename simplication
I have decided to drop the “Starfleet” part of the website’s name. I believe “Path to 2265” is a more clean site name and it matches the domain name now! Plus, both sides of the “to” are ‘balanced’ with four characters each now (as long as you’re not counting spaces)!

Reimagined search engine capabilities
For a long time, the searching capability and ship report part of the website have continued to rely on the fairly crude MySQL calls demonstrated all the way back in September. By early November, I upgraded to using PHP Data Objects (PDO) for enhanced security and code quality. Now, I have moved to class encapsulation as I become more and more proficient with coding in PHP! So with this object orientated approach, the code required to connect and query the database can be contained and interacting with the “SearchEngine” object can be securely controlled by only allowing certain methods with certain argument sets to be called. The search is also now (FINALLY) a tag-based search and I am currently developing an algorithm that can weight the results of one or more SQL queries and display the most relevant results to the user! I’m thinking about making a separate post to describe the process of doing this and its benefits in more detail, so stay tuned for that! But for now, I’ll leave you with this screenshot:

searchengine class
Most of the code has been collapsed from view since it may have sensitive data

Sitemap
Thanks to the new search engine capabilities, I have been able to reuse the SearchEngine class for other new features such as the website’s sitemap. Essentially, constructing the sitemap is done by querying a database for a result containing all the pages belonging to the same category. The SQL code is the same as a user searching (for now though, more about that later), so a SearchEngine object can be used without any problems.

Click here to see the sitemap!

SS Polaris progress
There is finally some progress on my second design project! I have taken a u-turn on the nacelle placement, and I have stripped some details that I thought made the design too advanced. In return, I tried to pepper in some details that make the design both more unique, polished and maybe industrial. Instead of having that weird dual deflector system mounted on top, the nose of the ship has been cut away to reveal one large deflector/communication array that I hope adds emphasis that the design relies on communication (since it is a diplomatic vessel). The new dish is also surrounded by some missile bays. The design will not have any energy weapons.

It’s quite funny, this design was developed without specs and was required to be developed in a week! Yet, it’s taken like two months or so to get to this stage… xD. Hopefully lesson learnt – ALWAYS iron out design specs ’cause it will just cause headaches later on.

comparison
Polaris: before (top) and after (bottom)

EXP-type Warp Reactor
I have added a new early UESPA reactor to the database. It is an attempt to explain how and why Earth had a matter/antimatter reactor (on deep space probe Friendship 1) so early on.

You can read about it here!

Progress gallery & milestones article
I’ve added these fun articles to show the progress and effort that was put into Path to 2265. Progress gallery is already up to do (mostly), but milestones still needs it content.

Chapter 1 proofreading
After discovering some grammatical errors on this chapter of the History report, I am currently in the process of thoroughly proofreading it!

Discontinuation of the “Todo” page
In all honestly, the page was only created for myself as a temporary tracker whilst I worked on the website. It was a place where I could list issues when I found them for later solving. Now that I use GitHub for issue tracking and source control, it has become redundant and will be removed from the website soon.

What’s the come!
My main focus is developing the search capabilities further right now. I soon hope to have an intelligent tag search with proper result ordering and sorting.

SS Polaris is nearly completion. So I might roll that out soon. The design documentation for both SS Voyager and SS Polaris need proper attention and revamping.

Chapter 2 (“Space Boomers”) should be completed in the next few weeks too!

And I think that’s that for today!

UESPA-9 finished, early warp reactors added

Well, I’ve just finished my UESPA-9 design in time for today’s update! Take a look at the development of the design:

uespa9_final
Late-August to mid-October 2017 development

I should make it clear than not everything about the design is finished. An orthographic and internal schematic is yet needed to give a complete picture, but this complete sideview will be enough to allow me to begin incorporating the design into the website fully. By the end of today, I should have most of the ship’s database entry done. By this time next week, I should also have a few paragraphs about the ship written for insertion into chapter 1. For now, you can read more about the design here!

Another significant addition to the website is a section of the (currently only UESPA) database dedicated to warp reactors. Since reactors are probably the single best way to signify technological development in starships, I decided it was time to put some attention there. Currently, information on the Cochrane-type fusion, Yoyodyne-type pulse fusion, and Cochrane II-series fusion reactors is present (which are written in chapter 1 and 2 to be the most prominent reactors in the mid-to-late 21st century). A Yoyodyne II-type pulse fusion reactor page will be done within the next few days to compliment the completion of the DY-732-class ship database entry next Thursday.

Have a good evening!

My first original ship

15th October.

That’s the date my Star Trek-themed website will be fully launched and online. As that day approaches, I will be continuing to refine the website’s design and adding launch content. Today, I am currently working on my first original ship design for the website. But before we get into that, I think it is about time I brief what this website is all about.

“Starfleet’s Path to 2265” is as nerdy as it sounds. It is mainly a creative written piece on the subjective fictional history of starships belonging to Earth and Federation design. It’s based around the Star Trek’s prime universe and conforms to canon (mostly). My biggest intention is to fill in the blanks in the timeline between Star Trek: First Contact and Star Trek: Enterprise. Over a year ago, I wrote a small piece about SQL and PHP (In the deep end: MySQL & PHP) that demonstrated an older project called the “Federation Starship Database”. It is kind of like a continuation of that with a refined goal and scope. Pre-TOS and TOS ships are my favourite from Star Trek, and this website is dedicated towards them.

Now, the ship design.

This first of many starship designs I am creating is an early explorer of the United Earth Space Probe Agency, SS Voyager (UESPA-9). I have designed and written the ship to be an early ambitious failure – a complex deep space explorer design in a period of Earth’s history where it is still suffering from the effects of a World War. A recipe for disaster. The design is largely based on a successful canon design from the same period, SS Conestoga (which I have given the registry of UESPA-8).

SS_Conestoga
The canon SS Conestoga, the ship my design is largely based on. Image from Memory Alpha, used under Fair Use.

In order to explain my process, I have briefly documented the design process here. The first thing I did was sketch up some small low detail forms for the ship based on a few well-known references from the same period (SS Valiant of 2065, SS Conestoga of 2067 and DY-500-class of 2076).

uespa9_stage_1

I found that the last form I did was the one I liked the most, as well as the most unique. So I took that form, refined the details, and did some basic annotations on the design.

uespa9_stage_2
Correction: the size measurements should read “145 (length) x 20 (width) x 30 (draft), 50,000 metric tonnes”. In hindsight, the width is far too small anyway and should logically be around 50 to 60 metres.

I then roughly recreated the form on a CAD software (I use TechSoft’s 2D Design V2) so that the design would be confined to a proper scale. I then made a copy of the form and revised the layout of the ship to better suit the length and draft I specified in my annotated drawing (although my specified width of 20 metres will likely cause problems and I am now presuming the width to be around 50 to 60 metres to accommodate the “wing” span of the nacelle pylons).

uespa9_stage_3

Finally, I produced a colourised detail basic render of the ship as a current progress preview for this blog post.

uespa9_stage_4

I hope to have this design completed by the end of the week, and it will be included in my next week’s blog update for the website. Have a good day!