Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

FYI dbf desktop development security risk

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • FYI dbf desktop development security risk

    This applies to desktop apps created with .dbf table structures only.

    The Alpha documentation clearly states the following for password protecting your code i.e. scripts, etc.

    How to password protect your scripts to prevent users from changing the scripts.

    If you are designing an application for others to use, you may want to password protect your scripts to prevent users from changing the scripts. You may also have created a commercial application in Alpha Anywhere and you may want to protect your intellectual property by hiding the scripts. Alpha Anywhere allows you to password protect any script that is attached to an event . a Global Script, or a Global Function. Your script must be in Xbasic. You cannot password protect Action Scripts. If you need to password protect an Action script, you must first convert it to Xbasic. To password protect an Xbasic script:
    • Edit the script.
    • Add the following to the first line of the script: 'PASSWORD
    For example if you want to protect a script with the password FOO, you would add the following to the first line of the script:

    'PASSWORD FOO


    The help document would indicate to a developer that ANY xbasic script you create if password protected is safe and secure from prying eyes. This will give the developer a false sense of security when developing security applications.There should be a disclaimer or at least an explanation regarding scripts attached to layout events such as OnInit, OnKey, OnTimer, etc. Any event attached to a form layout event or object event, EVEN when password protected is not secure in any way from the end user or other developers. This is a huge development security issue.

    I just discovered this and it is not in the documentation. I have hundreds of scripts attached to form events and object events, everyone of them are password protected as described in the documentation.
    However; if you open any .DDM file with a text editor, all of your code including the password is clearly visible for the whole world to see. It does not matter if the tables are encrypted, encrypted tables keep your data secure but not your code.

    This can be a huge set back when you discover it late in development as I have.

    Now I have to go back and create global scripts and function for every OnInit, OnKey, OnTimer and many more events in order to keep my code secure. My point being is that this should have been clearly stated in the documentation years ago.

    I hope this helps someone else not make the same error I have.

    Just when you thought it was safe! :(



  • #2
    It is so much easier to write all code in UDFs and call the UDFs from button and layout events. Code written inside buttons and layout events is a PITA to get to and work in. The only code I have on button on push events and layout events is a single line <udfname>(). Somewhere on this Message board years ago there was a thread that discussed this entire topic that I shared in, that I believe was started by a gentleman named Ira. In the old message board I would be able to find it for you, but not in this current message board.
    Mike W
    __________________________
    "I rebel in at least small things to express to the world that I have not completely surrendered"

    Comment


    • #3
      Mike is spot on...

      The discussion took place on the board years ago on or around version 5's release. As to it being started by Ira Perlow, I cannot say for sure. He certainly was a power player back then, and his participation is missed. Alpha Five had transferred ownership for a brief period, and development had stopped until that massive release of version 5 after Selwyn reacquired title of the company (thank goodness.)

      I not sure I ever saw it in the main documentation, although I did think it was with the runtime documentation.

      Selwyn was on the board night and day back then, and I think the AEX compiler was added because there was no way to encrypt the table support files. It was left in as a simple way to keep the honest people honest.

      I am sorry to hear this means some significant effort on your part that you did not expect. As Mike points out, those message board posts are probably long gone.


      As of now, this was copied from within AA, albeit a place you may not have explored under compiling your scripts and functions into a AEX library. Noted, it does not point out how vulnerable code is when placed in other areas of your app:

      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.



      Knowing what I do knew from way back when, I never placed any code of significance on the forms or buttons. I always use SCRIPT_PLAY() referencing a GLOBAL script, or created USER DEFINED FUNCTIONS.

      If you really want to do the best you can to protect your intellectual property within AA, be sure to compile your scripts and functions into an AEX library. Take note of the use of OPTION ENCRYPTED_TOKENS.

      https://documentation.alphasoftware....%20AEX%20file?

      Comment


      • #4
        Be sure to look at SCRIPT_PLAY_LOCAL(), too, as it may be useful.

        Comment


        • #5
          Thanks for the suggestions.

          I do use script_play_Local() many places in my apps and also have many global scripts and function that I call regularly and have placed the OPTION ENCRYPTED_TOKENS command with all of my global scripts and functions. Albeit, I have not created the AEX file yet, I was waiting until development was completed.

          From the documentation, I figured my code was secure with passwords just as it says it is. It's going to be a major pain to create scripts or functions from 400 to 500 lines of code in the OnTimer events, etc. I'm not even sure how to make all of the code work from scripts and functions in the OnTimer events, plus I have a lot of Control_User Timer objects on dialog forms that I'll need to re-code somehow. Had the help documentation set me on the right path from the get go, I would not be in this mess. It could have simply stated that "your Xbasic code is not secure when placed within layout events or object events, it can only be encrypted when placed in global scripts and functions on the code tab". Wow, 1 or 2 sentences could have saved a ton of unnecessary work. Hind Site is a Bitch!

          Comment


          • #6
            You wrote:
            It's going to be a major pain to create scripts or functions from 400 to 500 lines of code in the OnTimer events, etc.
            Why do you believe it a major pain?
            1. Go to the code text on the on timer event and at the very top of the code write a UDF name - like - on_timer_Form1() and follow it on next line with "end". Save the code here until sanguine all is good.
            2. Copy the on timer event code text (below the UDF call) to the clipboard
            3. Go to code tab in control panel, select menu option "New", select Function, name the function - on_timer_form1 - and paste the code between the Function - End Function region and save.

            Done!

            And why bother with script_play_(). Very, very little need for scripts. The only place I found scripts are absolutely necessary are within Supercontrol Events. Supercontrol events won't/can't call UDFs and will only call scripts. When all the code is in UDFs, you have so much more control of your application. In the current app I am managing/developing, there are 1479 UDFs, and I have a UDF that searches the code text in all the UDFs in the application in 17 seconds to get a list of codes with a particular string construct. I have even made the capabilities to add and edit UDFs existing within a customers run-time app using TeamViewer relieving me of the needs create and re-distribute an update. UDF's are the key. The conversion will be well worth it!

            Mike W
            __________________________
            "I rebel in at least small things to express to the world that I have not completely surrendered"

            Comment


            • #7
              Okay Mike,

              You are officially my new hero and a genius! That worked like a charm, I thought it would be a huge undertaking. I did not realize you could just toss all of the code into a function and it works without having to rewrite or change anything. Thanks for the expert advice, I can now get back to work and get this up and running. :)

              Robert

              Comment


              • #8
                This is still going to be a lot of work, but overall much less than I expected. I did find one issue so far, when I moved some code into a function, the variables were no longer available. I had to change all of the Layout Variables to Session Variables and that solved the problem. This should be a much more efficient use of code when finished and thanks again for the advice.

                Comment


                • #9
                  Robert, UDF's can give a value from the udf. You just have to declare it and fill it.
                  I use udf's a lot to do the heavy work and some scripts to call the udf's sometimes different ways.All code is saved in an aex file.
                  Much of your code can be derive by converting your operation, button pushes, and almost everything in alpha by letting alpha convert it for you. Then just a matter of coping/saving/naming a script. Then you can create a udf as needed.
                  Last edited by DaveM; 07-05-2020, 12:24 AM.
                  Dave Mason
                  dave@aldadesktop.com
                  Skype is dave.mason46

                  Comment


                  • #10
                    Thanks Dave, but I'm not a novice in the use of functions or scripts calling functions. This particular app has 82 functions almost all which return values. I have used all three methods - scripts, functions and form and object event coding. The latter in which I was not aware of the security vulnerabilities until I accidentally discovered it recently and it just made me mad, because the documentation is not clear on the matter. It should be in big bold letters - WARNING go the other way or your code may be compromised!

                    Of course I'm just being facetious, but it should have a serious warning on the matter because it is Alpha Software's responsibility to let the developers know of any issues that may compromise the security of the apps they develop with AS.

                    For example: I can remember a few years back when OpenSSL with their
                    libeay32.dll had some security issues and could be hacked. AS let everyone know that they needed to update their libeay32.dll. So then, why is this not a big deal?
                    If my code can easily be compromised, to me that's a huge deal, and I most certainly want to know about it so that I can fix it if they don't.

                    Comment


                    • #11
                      A long time ago (in A5v5 maybe?) I came to the conclusion that there was no point in password protecting anything other than global scripts and functions. Any code that needs to be proprietary can be put in a global function. Even the forms aren't worth password protecting because everybody sees the form and could easily reproduce one with the same appearance.

                      There is also an issue with passwords in field rules. They don't work at all. If there is any concern about having them in your app, let me know. I have a function called AIMS_field_rule_pswds() that will check all field rules for passwords and let you know where to find any that exist. (Hmmm, maybe I should do the same for those layout events. I think it would only be a minor change to an existing routine IF I can check for a password without knowing what the password is - i.e., an event with a password returns something different than a blank event and doesn't stop the routine with an error.)

                      Fwiw, think seriously about each of those events you are changing to functions just to save yourself some hassle (been there, done that). There is no point in changing simple, short scripts that don't have "proprietary" code. If the script is so simple that anybody could easily figure out what to write (e.g., a script to open a form to a specific record), there's not much point in wasting time changing it to a function. If the script is long, regardless of how easy it would be to rewrite, you might want to consider making it a function - either now or in the future - just for ease of debugging/updating later. It's much easier to debug a global function than to switch back and forth between edit and view mode to test changes on a layout. Below is the code I use in the beginning of my functions that rely on a layout being open (it's saved in my Code Library because I use it so often):

                      Code:
                      '2020-05-11 Routine to get pointer to "parentform" even when working in Code Editor.
                      IF eval_valid( "parentform.this" )
                         fp = parentform.this
                      ELSE 'This section is just for dev work when there is no parentform because we are working in the code editor.
                         form_name = "SCF02_Split_Credit_Parts"      'Change name as necessary for dev work.
                         IF eval_valid( form_name + ".this" )
                            fp = eval( form_name + ".this" )
                         ELSE 'For dev work where I forgot to open the form first.
                            fp = form.view( form_name )
                            Code_Editor.Activate()
                         END IF
                      END IF
                      Finally, I also have a function for adding/removing (or checking for) passwords in global scripts and functions. I got really tired of dealing with passwords when doing serious development work on a large app so I came up with a function that will add/remove passwords from all global scripts and/or functions. This way I could quickly remove the passwords while doing dev work then add them back in when done. It only takes a second or two to run. Of course, you can't remove a password unless you know what it is. I'll attach the function but to use it effectively you need to have it in an aex file that is always loaded in your dev version. I have an app called AIMS_Developer_Code that has probably 100 functions just for dev use. I export it to an aex file after an update and put the aex file in each version of Alpha that I have loaded. I update it often enough that one of the functions in that list is one to copy the aex file to all those versions of Alpha. (I have one customer still using A5v5!!)

                      AIMS_scp_passwords.txt

                      Note: That routine to add/remove passwords will only remove the specific password you specify. Any script/function with a different password will not be changed. But, when you add a password, it will be added to ALL scripts/functions that do not have a password. In other words, in an app I have where the customer also has access to the code, I have a special password for some of my proprietary functions and these needed to be added manually before using the routine to add/remove their password on the other functions.
                      Attached Files

                      Comment


                      • #12
                        Put your UDF's inside a class and then password protect the class. One advantage of using classes is that, you can put unlimited number of UDF's inside it so you will only have to password protect the class. You may also compile your code to AEX.
                        Create windows desktop applications using pure web components.

                        Visit https://a5wd.com and download our Alpha Anywhere Library.

                        Comment


                        • #13
                          Thanks Roland, I will research it.

                          Comment


                          • #14
                            Originally posted by R Kenyon View Post
                            Thanks Dave, but I'm not a novice in the use of functions or scripts calling functions. This particular app has 82 functions almost all which return values. I have used all three methods - scripts, functions and form and object event coding. The latter in which I was not aware of the security vulnerabilities until I accidentally discovered it recently and it just made me mad, because the documentation is not clear on the matter. It should be in big bold letters - WARNING go the other way or your code may be compromised!

                            Of course I'm just being facetious, but it should have a serious warning on the matter because it is Alpha Software's responsibility to let the developers know of any issues that may compromise the security of the apps they develop with AS.

                            For example: I can remember a few years back when OpenSSL with their
                            libeay32.dll had some security issues and could be hacked. AS let everyone know that they needed to update their libeay32.dll. So then, why is this not a big deal?
                            If my code can easily be compromised, to me that's a huge deal, and I most certainly want to know about it so that I can fix it if they don't.
                            I apologize if I inferrd anything. I know you are no novice. I agree, it should have been made clear the code can be exposed. Just password protecting does not do the job if the perpetrator is familiar with alpha. The aex file seems to be the best, although I have been told it can be broken as well. I have not tested that



                            Dave Mason
                            dave@aldadesktop.com
                            Skype is dave.mason46

                            Comment


                            • #15
                              No problem Dave! If in fact the aex can be broken, then they must be using some really lousy encryption. Even if they're using blowfish, it should be very secure.

                              I thought I heard somewhere that alpha's default encryption is Blowfish. The web says this about it: "Blowfish's security has been extensively tested and proven. As a public domain cipher, Blowfish has been subject to a significant amount of cryptanalysis, and full Blowfish encryption has never been broken."

                              Comment

                              Working...
                              X