What's New - August 2016

cht_august2016.png

videoinproduction.gif

August 31, 2016

Build Update 20C.03.00 Now Available (Part #1)

Today is the end of the month, August 31, 2016.

We've finished posting our third 20C Build update (i.e. 20C.03.00).

In this series of postings, we want to provide a brief overview of CHT's across-the-web installer technology as shipped with this 20C.03.00 update.

The underlying philosophy behind this recent work, is eCommerce.
 
The assumption is, you have developed something (software, documents, videos, etc.) which you wish to distribute and install onto windows machines. You are, Clarion developers, after all, and with Clarion you develop presently, only windows software.
 
Perhaps you are an independent developer, writing apps that you sell to a broad general market or vertical market. On the other hand you may be a corporate developer who has to deliver and update his work to a dedicated corporate group or division.
 
Regardless of your situation, we think with these installation servers and their matching installer applications included in this build you will find an eCommerce operating model that suits your needs for digital product distribution and documentation delivery.

In the next three posts, we will outline three pre-built servers and five matching pre-built installers that illustrate five different installation models ranging from free-distribution, to one-time installation, to updatable one-time installation, to renewable subscriptiion-model distribution.

This work is all done in APP format, via CHT Templates and Classes, in the standard manner that you're familiar with. We will introduce parallel XSA-PROJECT kits that provide this same work in a template-less manner, but with this build release we're providing Clarion applications, not Clarion projects.

The servers (pick one) are ready to run. You shouldn't have to do more than compile them, configure the IP and PORT, and run them on your Windows hardware, attached to a viable high-speed internet connection. Servers can be internet-public or internal-WAN only, depending on the IP address and port you ask them to monitor and deliver to.

The installers are ready to run and test also. Since the installer portion of your delivery system is going to be visible to your customers, obviously you'll want to make some cosmetic changes to suit your brand. The servers are IP pre-configured to deliver and test via IP (http://127.0.0.1:88/) which you'll recognize as localhost IP on port 88.

We suggest you test them by setting the matching server to the same IP:PORT and run this pair as often as it takes to understand what's going on before customizing the installer and setting up the server on your own delivery-hardware platform.

The IP:PORT are declared in the first few lines of the installer MAIN procedure as below:

sampleinstaller001.png

All installers deliver an HZO container named hndxsainstallexample.hzo. To run your test you need to place this container into your server root. We've even provided the above named pre-built container in your install (find it in your /HNDAPPS/) directory. Then build your own and modify the Installer Template prompts to match names and titles etc. of what you're delivering.

Get the server-installer pair delivering reliably before you attempt to move the server to a new IP on other hardware. Only then, reconfigure the installer IP:PORT (and recompile). Get that working, and then modify the cosmetics, since that won't impact functionality.

In the next post, (part #2) we'll describe in text and pictures the operation of the first server-installer pair (HNDSLFSV.APP and HNDSETUPMKR.APP).

In the following post (part #3) we'll describe in text and pictures the operation of the second server-installer set: HNDSLFSVXSA.APP, HNDSETUPMKR_XSA_HC.APP and HNDSETUPMKR_XSA_LOOKUP.APP. This set provides two different installers which you can read about in that post.

In the post following that, (part #4) we'll describe in text and pictures the operation of the third server-installer set: HNDSLFSVXSA3PART.APP, HNDSETUPMKR_XSA3_HC.APP, HNDSETUPMKR_XSA3_LOOKUP.APP. This set provides two different installers also, which you can read about in that post.

Continued in Part #2 below.

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 31, 2016


Build Update 20C.03.00 Now Available (Part #2)

This informataion deals with server app HNDSLFSV.APP and installer app HNDSETUPMKR.APP.

This installer/server pair performs an unsecured install, not protected by a password. Two other servers and four other installers provide various forms of install-protection either by password or by user identity. You can read about these other server/installer implementations in parts #3 and #4, below.

Now back to server app HNDSLFSV.APP and installer app HNDSETUPMKR.APP...

Compile both apps as-is and test locally in the following manner (server image next).

hndslfsvserver001.png

Set it up as pictured. The IP in use here is 127.0.0.1 otherwise known as localhost, using port 88. (i.e. http://127.0.0.1:88/). This IP is not available in the IP dropdown. You need to type it into the Server IP field followed by the tab key.

We've set this server's root directory to c:/web/. This just happens to be where we keep a local copy of our website, so there's plenty of stuff to display from there. We always develop our new and revised web pages locally and then post them up to our web server's root directory. Remember, this server also acts as a web page server, where your company advertizing and help pages can be placed.

What directory name you use here is up to you, the minimum you need to make the installer work is to place the hndxsainstallexample.hzo file in this directory, even if you don't plan to serve pages. The installer is configured to pick the file up from the server root, but it's easy in your own case to have the file picked up from a subdirectory of the root, if for no other reason than for organizational purposes.

(Installer Image Next):

hndsetupmkr001.png

This installer is encoded to the above localhost IP address and port. Use the IP:PORT settings as-is in order to test against the above server.

(Template Settings Images Next):

hndsetupmkrtpl001.png


hndsetupmkrtpl002.png

(Other images related to this installation):
--- INSIDE THE INSTALLATION CONTAINER ---

hndsetupmkrtpl003.png

From the construction of the installation container you can control where in the root expansion folder the contents of this container will be expanded. Since from our template setup the installation root folder is HPROP:HNDAPPSROOTC10 (in our case c:/clarion10/ that means the installation app HNDPREVIEWER.EXE is going to be expanded into c:/clarion10/hndapps/. This is also the case for the .CER file. It is designated in this case also for the same directory. (see next image).

--- INSIDE THE HNDAPPS DIRECTORY ---

hndsetupmkrtpl007.png

--- INSIDE THE INSTALLATION LOG ---

hndsetupmkrtpl004.png

--- INSIDE THE DESKTOP INSTALLATION LINKS FOLDER ---

hndsetupmkrtpl005.png

--- INSIDE THE INSTALLATION TARGET HZO DROP FOLDER ---

hndsetupmkrtpl006.png

Get the server working and delivering using the configured local IP:PORT before you change the location of the server and the IP:PORT embedded in the installer.

Continued in Part #3 below.

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 31, 2016


Build Update 20C.03.00 Now Available (Part #3)

This discussion is about an installation server application called HNDSLFSVXSA.APP and two related installers called, HNDSETUPMKR_XSA_HC.APP and HNDSETUPMKR_XSA_LOOKUP.APP.

This server uses our new XSA security protocol, introduced last update with CHT-XSA-PROJECT-KIT-01. This security protocol passes a USERNAME:PASSWORD string to the server via the HTTP header. This string is encrypted by the client and decrypted by the server. Once the server decrypts this USERNAME:PASSWORD string it is compared against the USERNAME:PASSWORD configured on the server via the configuration dialog. (see next image)


xsaserver001.png

If the USERNAME:PASSWORD string sent from the installer matches that which has been configured on the server, the installation is allowed to proceed. If it fails to match, the installation is terminated such that the installation container is never sent to the installer.

The two installers are configured identically internally as to what they're downloading and where it will be placed. The only difference is the "Authentication Model" switch configured on either installer. The _HC.APP (with "HC" for hard-coded) is configured as follows (see next image)


xsaserver002.png

The second Authentication switch from the left, indicates that the USERNAME:PASSWORD string will be HARD CODED into the installer application. As you can see two fields have been provided on the template where these two values may be entered.

This HNDSETUPMKR_XSA_HC.APP application may be "turned off" or invalidated by changing the server-side USERNAME:PASSWORD configuration. This type of installer does not/can not distinguish between users. All users with an identical copy of this installer are "turned on" and "turned off" by the simple adjustment of the server-side security configuration.

The second installer for this server, HNDSETUPMKR_XSA_LOOKUP.APP refines this situation somewhat as it allows the installer user to change the USERNAME:PASSWORD string submitted to the server. This installer's "Authentication Model" settings are configured as follows (see next image).


xsaserver003.png

The HNDSETUPMKR_XSA_LOOKUP.APP sets the third Authentication switch from the left. The USERNAME:PASSWORD strings are not hard, coded, they're looked up in the registry. If these do not exist in the registry, or if the values currently in the registry are incorrect and result in a failed connection to the server, this installer pops up a two-field dialog which gives the installer user a chance to add, or update the USERNAME:PASSWORD string required for a successful connection. (see next image)


xsaserver004.png

If/when the server-manager changes the master USERNAME:PASSWORD on the server once again, all previously correctly configured versions of this HNDSETUPMKR_XSA_LOOKUP.APP installer are invalidated.

However, users who will continue to install, and who have renewed or paid for an update (whatever your policy dictates) can be re-connected by sending them the latest USERNAME:PASSWORD string. Hence the installer does not have to be replaced, just reconfigured on the installer-user-side.

While this second installer for server HNDSLFSVXSA.APP is more flexible, it still does not provide INDIVIDUAL USER control. When the server USERNAME:PASSWORD are changed, all installers are disconnected simultaneously. The "XSA_LOOKUP" installer version however, does provide an easy way for users to re-configure their installer to the latest server settings.

This server-installer combination is probably most useful when you're providing a common installer to employees of a company, all using the same set of your apps.

The configurable installer in this installer pair, can be a useful when rolling out a new update to groups of these employees at a time. First, change the server password to invalidate all installations and then send password updates only to that part of the employee group which must update first, and so on, in waves until all are again up to date.

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 31, 2016


Build Update 20C.03.00 Now Available (Part #4)

This discussion involves an installation server called HNDSLFSVXSA3PART.APP and two related installers called, HNDSETUPMKR_XSA3_HC.APP and HNDSETUPMKR_XSA3_LOOKUP.APP.

This server provides individualized control of user-installs. The server uses a user-lookup table, which in this case is an SQLITE table called "Customer" located in a SQLite container file called HNDSLFSV.SQLITE. The "3PART" component of the server name has been added to remind you that this server's authentication method uses a 3-part login string consisting, of emailaddress,serialnumber,lastname.

While the 3 components in the login string do not really need to consist of an email address, serial number and last name, developers using other real-world values must make sure that at least, the first two of the 3 components in this string are unique to the individual.

Uniqueness is a requirement for correct identification at login, since a fetch on one or the other of these unique keys (or both) is used by the server to authorize or reject the installation.

We've provided, with this CHT update, a new maintenance app called HNDSLFCUS.APP which can be used to maintain the server-user data table. In the next image is a snapshot of the update form from that app to give you some insight into the user's configuration.


xsa3server001.png

You can find this HNDSLFCUS.APP in your /HNDAPPS/ directory alongside the server and installer apps being discussed here.

More needs to be said about server-user configuration as the server can be made to react to the values in the user-account record, but this is not the place for a detailed discussion of that. Suffice to say, in the current set of installers, the server reacts to the "Locked" field set to "checked" by refusing installation as well as to the expiration date.

This single feature allows you to invalidate one user's installation privileges without affecting other users. This model is best suited for an across-the-web type of business where users do not necessarily belong to a group or company.

The first of two installers matching this HNDSLFSVXSA3PART.APP server, is an installer application called HNDSETUPMKR_XSA3_HC.APP. It hard-codes the 3-part login string on the template. The next image illustrates how that was accomplished.


xsa3server002.png

The second of two installers matching this HNDSLFSVXSA3PART.APP server, is an app called HNDSETUPMKR_XSA3_LOOKUP.APP. It looks up the user's login string in the registry. The next image illustrates how that was accomplished on the template.


xsa3server003.png

This installer looks up the 3-part login string in the user's registry. If not found or if found to be invalid, the installer pops up a dialog asking for the correct values to be entered. (see next image).


xsa3server004.png

It's clear that this last server-installer pair most closely resembles CHT's subscription model, in that it allows the selling-devloper to control, the operation of each customer's installer separately and yet still provide everyone with the SAME INSTALLER exectuable.

Our subscription model really is no different than that of any other software vendor's "one year free upates with every purchase" model. If you provide a period of time after purchase for the user to update his/her software without charge, you're really in the subscription business, whether you like the term "subscription" or not. In which case, this server-installer authentication model is for you.

As we said at the outset, in POST #1, test the server-installer pair that's right for you, locally on your development machine first using the http://127.0.0.1:88/ IP:PORT first, until you have it working correctly. We've supplied a copy of the HNDSFSV.SQLITE data base container file. And don't forget to look into HNDSLFCUS.APP to experiment with a user-configuration of your own.

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 31, 2016


August 22, 2016

We've decided that on or near the end of August 2016 there will be another intermediate update numbered as Build 20C.03.00.

From the XSA-PROJECT-01 work that we did, circling the topic of e-Commerce, it became obvious that more could be done in this e-Commerce area, sure more XSA projects, but also in the pre-built template-based application area.

By the 31st of August, we should be in a position to release several new installer model applications, based on the original HNDSETUPMKR.APP, and several new server applications based around HNDSLFSV.APP.

The apps are complete as of today, and the template called GENERATEHNDSETUPMKRINSTALLDETAILS, has been further enhanced to provide for a range of security models right on the template.

In this iteration, there will be 3 example servers and 5 example installers:
(1) Server: HNDSLFSV.APP - Installation containers may be requested from the installer without the requirement of a password.

Matching Installer: HNDSETUPMKR.APP this installer, like the server, requires no password protection. Use this installer-server pair in the event that what you're distributing requires no password protection and is freely available to anyone with a copy of the installer.

(2) Server: HNDSLFSVXSA.APP - Installation containers may be requested from this server only by presenting an XSA-Style username/password string (as in XSA-PROJECT-01) configured on the server from a popup dialog. Reconfiguring this username/password string on the server, will immediately lock out all installers that were keyed to it. One type of installer (the hard-coded one described below) will then be obsolete, while a second type (the configurable one, also described below) can be user-reconfigured.

Matching Installer - HNDSETUPMKR_XSA_HC.APP - The username/password are hard coded (hence HC in the app name). When the username/password configuration on the server is changed, this installer is obsolete and must be replaced.

Matching Installer - HNDSETUPMKR_XSA_LOOKUP.APP - The username/password are looked up from the user's registry. When first run, this installer pops up a dialog with which the user can enter the correct username/password values. After that, installs will proceed without user-intervention unless the server is reconfigured. At the point that the installer fails due to the username/password on the server having been changed, this installer again pops up its configuration dialog and asks for new credentials to be entered. Re-instating user access, then is only a matter of sending new login information, depending on your update policy.

(3) Server: HNDSLFSV3PART.APP - This server uses an SQLITE customer lookup table in which each separate user is registered, similar to the way CHT handles this user authentication. Every customer is given a 3-part login string (eg: email, serial number, last name) which is unique to them.

We've built an app called HNDSLFSVCUS.APP with which to maintain this customer table.

Matching Installer -- HNDSLFSV_XSA3_HC.APP - The login string is hard coded to the customer's login parameters. When the customer is inactivated or expired, (you make the rules, here) the installer is obsolete and must be replaced for the customer to continue with download installations.

Matching Installer -- HNDSLFSV_XSA3_LOOKUP.APP - The customer login-string is looked up from the user's registry. When first run, this particular installer pops up a dialog with which the user can enter the correct login string. After that, installation proceeds without user-intervention unless the customer is inactivated or expired or they've entered the login information incorrectly. Again, you make the rules here.

This installer, on failing to connect will pop up its configuration dialog and ask for new or re-entered login credentials. The installer does not become obsolete unless update privileges are not re-instated in the server's customer table. (Manage customer table with HNDSLFCUS.APP).

All previous versions of HNDSETUPMKR.APP have been removed and replaced with the installers named above. Each of which is relegated to be used with one of three different installation server types, also named above.

Since the XSA-PROJECT-01 server works like the #2 server above, an upcoming XSA-PROJECT-02 kit will work like #3 above, utilizing an SQLite customer registration table. This project kit will also provide a customer maintenance utility based on HNDSLFCUS.APP. And of course, this whole kit will be a template-free, pure Clarion Project, like it's predecessor.

These three different server-authentication schemes and 5 different installer types should offer as much flexibility as you'll ever need to offer remote installation of your software, of your documents, and videos whatever it is you're selling across the web. And of course, the server in each case will serve up standard static sales pages, as always, while acting at the same time, as an installation container server for your installers.

More in upcoming posts.

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 22, 2016


August 1, 2016

CHT Build Update 20C.02.00 Released

We've released Build Update 20C.02.00 for Clarion 10, to your Webupdaters. This update is dated Jun.30.2016.

To update properly, please exit Clarion 10 and navigate to your Windows 10 START area in the lower left corner of your screen. There under "ALL APPS" you'll find a folder called "The Clarion Handy Tools C10". When you open this folder and see the listed items, you'll find at the bottom of the list an entry entitled: CHT WEBUPDATER C10 (UPDATE-INSTALL). RIGHT CLICK this, select "More" -> "Run As Administrator", and you're on your way.

The latest CHT WebupdaterC10 is labelled: JUL.30.2016.C300716. Older C10 Webupdaters will update themselves to this version automatically.

Before you start your update, please pull down the "Config" menu and check the item called "Auto Continue" if it isn't already checked. This ensures that "Continue" is pushed all the way through to the end of both the download installation phase and the decontainerization installation phase. We'll inform you on the CHT Support Forum, as well as via our monthly What's New Pages, of all relevant changes and additions in this build.

An emailed Build Announcement will follow in a few days with a full re-cap of what changes, improvements and additions have been added to the CHT Toolkit with this update. See also later entries on this What's New Page, for further announcements and information about this update.

 

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 1, 2016


The Latest Docs

The latest template docs are here: CHT Template Docs

The latest demo application docs are here: CHT Application Docs

The latest UTILITY application docs are here: CHT UTILITY App Docs

The latest BATCH-BOT and SNAPINS application docs are here: CHT BATCH-BOTS and SNAPINS Docs

The latest classes docs are here: CHT Classes Docs

 

Gus Creces
The Clarion Handy Tools Page
www.cwhandy.ca
gcreces@gmail.com
August 1, 2016

 


hnd_dozen.gif

chtcopyrightgray.gif