Deployment Guide...

[WayneS]

Looking for some expert guidance...

Suppose that an app is completed (whatever that might mean). To protect the code, I assume that:

(1). One compiles the scripts into a library (aex) file.

Should the aex file be renamed to something different? Under what conditions would you like to rename it? Pro's and Con's please.

(2). Under File -> Database properties one should hide the control panel.

Does this do the same as a startup form that utilizes controlpanel.hide()? Are there any advantages to doing (2) as opposed to the single line of code?

Side-step. By performing these two steps, will the developer be able to alter functionality in code such as one might do in a later release? How would you proceed?

(3). I would ultimately like to provide a link on a web page, similar to what Alpha does, that checks for updates - either runtime or app and then informs the end user of a new update.

I guess this is a shell for ideas. Any guidance would be appreciated as the help provided online does not really give a step-by-step approach to deployment. If it does, I missed it.

Thanking you in advance,
Wayne

[Keith Hubert]

Re: Deployment Guide...

Hi Wayne,

I think you need to do some experimenting on a dummy database to get the answers you are looking for.

Here is some info for you that is in the AEX compiler dialog

To ensure that your scripts cannot be seen by someone who opens an .AEX file in an editor, you can direct Alpha Five to encrypt all or part of each script when it is compiled into an .AEX file.
The following two commands can be placed anywhere in the body of a script or function:

OPTION ENCRYPTED_TOKENS

and

OPTION PLAINTEXT_TOKENS

These commands must be on line by themselves.

Any code that follows the OPTION ENCRYPTED_TOKENS command will be encrypted. Any code that follows the OPTION PLAINTEXT_TOKENS will not be encrypted. You can choose to encrypt an entire script, or just portions of the script. There is a slight performance penalty associated with encrypting scripts because Alpha Five must decrypt the script before it can be executed.

It does not matter which method you choose to hide the CP as long as you build into the app a secret back door. This can be as simple as a button with a password or activating a hotspot if the Administrator logs on.
With regard to updates, if you are referring to Alpha updates then don't even think about it, unless you are introducing a new feature to the application that you could not achieve before the new update came out. In which case that would be a new install and an update of the application with the new feature you have created for the client.

At least that has given you some things to think about.

[WayneS]

Re: Deployment Guide...

Hi Keith,

Thanks for the info.

Yeap, read similar info in the online help files. Also went through many posts on this board that talked about the button with a password. I would assume that if one created a copy of the entire directory before applying any aex compiling or the database properties -> hide control panel, that a "working copy" could be used for development. After any updates are incorporated, copy that "working directory" to a "product release" directory and then do the aex and hide control panel.

Often times when one develops an app, there are changes that need to be done at some point in the future, whether it is based on user comment or the developer wanting to add something - like a new form, report or even a table. I would consider those types of things a minor upgrade to whatever is released. The end users must then have some way to download the new updates. In my case, I would like to simply provide a method that the user can use to see if there is a new update available. This is the similarity to what Alpha already does.

Perhaps a major update would be the jelling of two apps. Based on what I read in various discussions throughout the board, I purchased Astrum. I found InstallMaker to be unreliable, especially in making an update (minor). Of course, introducing new software also introduces new potential problems.

From what I gather, that software sets up an xml file that is used to look at the version and some registry key. Don't exactly understand how to make that gel within an Alpha app. For instance, does one setup a button that goes to your website and check versions? Cannot phantom the code for this.

Your guidance is appreciated.

Wayne

[Michael Humby]

Re: Deployment Guide...

This is how i handle the scripts before deploying an application.

As Keith says i place option ENCRYPTED_TOKENS in every script

1. Via the CP on the code tab i right click and choose Export
(Take care here because Alpha defaults to the current folder so edit the default save path to your own choice outside of the dbase, otherwise a text file is there for the whole world to see)

2. i then right click and compile the scripts and functions

3. I then remove all scripts and functions

I think i am correct in saying that using this method there is no need to further password protect your scripts by including in the first line 'password mysecretpassword -this should become redundant.

Welcome other views on this subject.

Michael

[WayneS]

Re: Deployment Guide...

Thanks Michael.

So far if we put the piece together for a Deployment Guide for everyone we have:

Phase I - Protecting Your Code

1. OPTION ENCRYPTED_TOKENS (Contributor Keith Hubert, msg. #2)

Put in all scripts and functions but beware of runtime delay.

2. Export the Script (Contributor Michael Humby, msg. #4)

Items 1 and 2 in message.

Online info for Michael contribution:

To export a script

1. Display the Code tab of the Control Panel.
2. Select Code > Export... or Function > Export... or Script > Export... to display the Export Scripts and/or Functions dialog box.
3. Select the Scripts, Functions, or Scripts and Functions radio buttons.
4. Enter the name of the file to export in the Filename field or click to navigate to and select a file to replace.
5. Optionally, click Export All to display the Export Scripts and Functions to ASCII File dialog box.
6. Optionally, click Export Selected... to display the Select Scripts and Functions dialog box.
7. Place checkmarks to the left of each script or function that you want to export.
8. Optionally, click the Select All or UnSelect All buttons to make your choices.
9. Click OK.

3. Remove all Scripts and Functions (Contributor Michael Humby, msg. #4)

Is this acceptable and accurate so far?

Thus far the two contributions by Keith and Mike have shed a great deal of light on the procedure(s) we all should be using or minimally consider for deploying an application.

Are there any other suggestions for proceeding?

Wayne

PS. Hopefully by the end of this we will have developed the deployment guide that all of us can use as a "recipe" or algorithm.

[Keith Hubert]

Re: Deployment Guide...

Hi Wayne,

To make small changes to a clients app you should have a good look at this thread here.

You have an export button on your machine and the import button on your clients machine, which would be on a Utility form, which could only be opened by a person with the authority to do so

[csda1]

Re: Deployment Guide...

Hi Wayne

Protecting you Intellectual Property (IP) in Alpha Five is the exact subject of a future IADN course I will be giving. However, I'll give you a few tips, some may repeat what others have said above.

(1). One compiles the scripts into a library (aex) file.

Should the aex file be renamed to something different? Under what conditions would you like to rename it? Pro's and Con's please.

Name doesn't matter, except if it is the same as the application database's name and located in the same directory, it is automatically loaded.

(2). Under File -> Database properties one should hide the control panel.

Does this do the same as a startup form that utilizes controlpanel.hide()? Are there any advantages to doing (2) as opposed to the single line of code?

I don't believe there is any real difference, but make sure you either have a backup developer copy, or a secret way back in.

Side-step. By performing these two steps, will the developer be able to alter functionality in code such as one might do in a later release? How would you proceed?

If you delete all the code files, you need to keep a copy. My CSDA Code Utility has a LibMake function that will allow you to select or pass code lists to compile into an AEX without deleting the original.

(3). I would ultimately like to provide a link on a web page, similar to what Alpha does, that checks for updates - either runtime or app and then informs the end user of a new update.

All of my utilities do just that, and actually can perform the install of the update too.

Keith said to use OPTION ENCRYPTED_TOKENS, which is correct. Get a hex file dumper and look at an AEX, and if you can see any text, then you are may be giving away IP. Take a look at my AEX's with my utilities and you will find only what I want you to see in an AEX.

Passwords on code tab entries are good if not using in an AEX, otherwise they just get in the way. Passwords on layouts (like forms) and Operations are close to useless, and should be different from the code tab passwords.

Licensing is another issue, and I have had good success preventing unauthorized using my techniques, but have been trying to complete an advance licensing package that does all the heavy lifting, but it's still not ready. Secure Licensing can be real tricky.

But there are a variety of additional steps you can take to secure your app too. There is no perfection, but you can make it pretty hard.

[CALocklin]

Re: Deployment Guide...

I do things a little differently.

Regarding the original item (1) - aex files:

I don't bother with aex files. I find the maintenance aspect too much to bother with. Removing and restoring all the code is too much work. (I did create a utility to do it very quickly but even using that was too much trouble when I considered the limited additional benefit.)

Instead, I password protect all my global scripts and functions. (Take "scripts" to mean "scripts and functions" from here on.) That password is extremely difficult to break IF you don't use it anywhere else. It's probably as difficult as decrypting an aex file - at least for most of us. DO NOT use the same password to protect forms, events, buttons, etc. because they aren't nearly as secure. Use this password ONLY on global scripts and functions (the stuff in the Code tab).

The way to add a password to a global script or function is to put a comment beginning with 'password on line #1 of the script. Here's an example using a password of "fred":
'password fred

The one problem with that is that Action Scripts aren't as easy to password protect as xbasic scripts. However, one of the many utilities in my AIMS Grab Bag is designed to add/remove passwords on global scripts - including Action Scripts - and it can do 500 scripts in a few seconds. This utility will also add passwords to Action Scripts. The only thing you have to watch out for is that the passwords will be removed from an Action Script whenever it is edited. So re-run the the utility to add passwords again before distributing any update. Of course, that's a good idea even if you aren't using Action Scripts.

Another thing you should do that makes them even more secure is to add OPTIONS Encrypted_tokens even though you aren't creating an aex file. (Thanks to Ira for this one.)

Hiding the control panel:

When you hide the control panel, don't forget to allow yourself a way to get back into the app EVEN when on the user's computer using the runtime. You may need to have access to the user's data to fix it or troubleshoot a problem.

Hint: If it's running on my machine (and I use a weird machine name to help protect it), then, just to make my life easier, my "control panel access" button doesn't prompt for a password. (see api_getmachinename())