Grammar Captive

The email verification process has been completed.  As nearly always it has fallen short of my expectations.  Still, it is formidable in both function and design.

This week has been an exhausting week of Javascript and jQuery with very little to show for my effort.  Then too, never was the thought of Grammar Captive with me, as I was teaching myself PHP in Thailand in 2010.  It is, however, those many months of self-training that have made Grammar Captive possible today.

I have not tested the new verification system on Explorer, but it appears to work well with Safari, Chrome, and Firefox.

This week will be devoted to finishing the newsletter template so as to insure consistent and timely content in the future.  Hopefully, I will also return to podcast production very soon.

If you decide to sign up for Seven Gates, Grammar Captive’s weekly newsletter, please do so using the Seven Gates splash page.   For, it is there where everything is completely automated.

Roddy

p.s. Special thanks go out to W3Schools for helping to overcome at least one major hurdle — the PHP handler( ) function!

The backend to a successful email verification system has now been installed. Only the decoration (eye candy) remains.

So what is email verification!

Step 1 – The subscriber fills out a form and submits it.
Step 2 – His data is checked for proper format and passed through a filter to clean it of foul play (a possible malicious hack).
Step 3 – A hash (one-way encryption) is created from a randomly generated password and placed into a database along with the user’s email address and other less sensitive information that he entered into the subscription form.
Step 4 – A confirmation email is sent to the user along with the encrypted password (hash) in the form of a verification link.
Step 5 – When the user clicks on the link, the hash is sent to a webpage that compares the returned hash with the email address and the hash stored in the database.
Step 6 – If a match is found the user’s account is activated, and the user is informed of his new account via another email that contains his first free edition of Seven Gates, Grammar Captive‘s weekly newsletter.

The user’s password is never seen, but by the user, and only then, if it is sent to him. It is the hash that gets stored, and the hash cannot be decrypted.  For the moment, not even the password will be sent, as the user will have no need of it.  It will simply perish in the system.

This coming week will be spent on the completion of a personalized newsletter, the styling of the subscription page, and another unpublished podcast.

Roddy

Grammar Captive now has remote access to its MySQL databases and will begin the migration of its new email verification system very soon. In addition, the HTML formatted invitation to verify is complete. Even the format of the database (schematic) has been finished and work on the first newsletter has started.

The winds of spring are upon us.

Roddy

Grammar Captive can now automatically receive data filled out by a user, store it in a secure data base, and send an HTML formatted email with a verification link, image, and best of all — a greeting with the user’s name embedded in the message.

The next step is to receive the verification information, match its contents with the information in the data base, and return to the user a copy of his first Seven Gates newsletter. This second phase should be fairly easy, as all of the heavy lifting has already been accomplished.

It has been a very tough three weeks, but everything has been well documented and easy to retrieve for the next time.

Roddy

Rejoice! On this day there is balance between night and day.
Roddy

Grammar Captive will produce its first unpublished podcast this weekend in preparation for its spring launch.

In the meantime, your host is busy wrapping up two weeks of study and experimentation with PHP buffering, the creation and use of the mysqli, mysqli_result, and mysqli_stmt objects, and a whole host of SQL statements including CREATE, SET, SHOW, INSERT, and DROP to name only a few.
And, all of this just to understand a few lines of copied code used to set up a system of reliable email verification for new newsletter subscribers.

Security comes at a cost, and the Internet is a jungle with many predators.
It has been one very long, arduous, but highly productive detour.

Roddy

Grammar Captive can now create both permanent and temporary MySQL databases and tables on the fly, read their contents, and insert new content.

Most important at the development stage it can now destroy everything that it creates.  No need to worry about uncontrollable Frankenstein monsters at Grammar Captive.

This week’s time schedule has also been updated.

Roddy

Grammar Captive’s excursion into the world of MySQL has resulted in the aversion of a potentially serious error.

The variable that I had created for the user subscription date was mis-specified. It was falsely set to update with a modification of a user’s data.

There are now two dates: one that automatically records the date that the user subscribes, and one that automatically records that a user or administrator has modified a user’s data.

Roddy

There is a lot of free code on the Internet. Some of it is well constructed. Much of it is not. Accordingly, it is important that one is able to distinguish between the good and the bad.

In order to achieve this task good facility with the languages employed to create the code is paramount. To acquire this facility one is pushed and pulled in many directions at once, and it is easy to lose one’s focus, if one does not pay good attention. In effect, much time, patience, and energy are required.

Nearly all of the answers to one’s question are there, ready and waiting, but one must be sufficiently well informed in order to know how to construct effective questions. This requires a lot of self-training.

This is software development from the perspective of a mature amateur.

Roddy

In its current stage Grammar Captive is more about learning than it is teaching, as much of the code used in the project’s development is new to the developer — namely, me.

As a good general rule I try not to incorporate anything that I do not understand.  This means many excursions into the unknown with many new discoveries that are interesting, but not always directly applicable. Such has been my recent encounter with PHP’s output buffer.

While preoccupied with buffering I did realize one important facet of gathering user information that I originally thought to avoid, but have since decided to embrace — user authentication.  And this, for two reasons:

1) Insure that what goes into the database is authentic — neither spam, nor another unwilling user’s information, and
2) Provide comfort to users who are suspicious of Shared SSL security due to the “invisible” (backend) use of https protocol.

Alas! Another week of sacrificed potential income. Once again, the long run has overtaken the short run.

Roddy