PG Software Development

Hi Clifton,

I am making a system to allow students to create a personal folder system required by my program. I have a problem. Encrypted passwords cannot be saved to files. I ask the user for a password (twice) and then encrypt it using pgStringEncrypt (base64) with or without encodeURIComponent. The result is undefined. If I don't encrypt the password, the file is written correctly using XMLHttpRequest and the PHP file below.

Code: Select all

<?php
$err = 0;
if ( isset($_POST['endPath']) ) {
$filePath =  $_POST['endPath'];
}
$serverPath=$_SERVER['DOCUMENT_ROOT'].'/programs/';
$err = 0;
if ( isset($_POST['mydata']) ) {
    $err = file_put_contents( $serverPath.$filePath, $_POST['mydata'] );
    if ( $err === false ) $err = 0;
}
echo $serverPath.$filePath;
?>

I have used this PHP file regulary and until now I haven't seen this type of problem.

I would recommend using the code test page to make sure you really have a valid string to upload to the server:
https://www.pgsoftwaretools.com/powerpac/assessments/exec-js/index.html

It may be that you are incorrectly using pgStringEncrypt().

EXAMPLE:


var str = "mypasswordstring";
str = tbfunction_pgStringEncrypt(false, str, "", "base64"); //Don't personally recommend "base64" but it works; just not very secure
str = tbfunction_encodeURIComponent(str);
return str;
//RESULTS IN STRING: "bXlwYXNzd29yZHN0cmluZw%3D%3D"

You must use encodeURIComponent() to make the string safe to upload to a web server.
I think your example is returning an undefined string because your example is not sending a valid string to be encrypted (at least this is what your post implies).
 

I can't figure out what's happening. Could you have a look at this 9.01 test app https://www.mediacours.com/tb_examples/testPassword.zip if you have time, please?

I took a look at your actions and PHP code and here are my findings:

• The selected action below in your sharedAction is causing issues because of how the XMLHttpRequest() functions are set up to work.
  

  

  Delay causes issues in this sharedAction

  sharedActions.png (13.61 KiB) Viewed 1127 times

  
  Why does it cause issues?
  When ToolBook executes these actions, it looks for media delays (like the one highlighted above) and breaks the action sequence into sections based on the number of delays used. So in your case, the interpreter will immediately execute the first part before the delay AND set a timer of 200ms to execute the second portion. The problem is that each Display (or JavaScript alert) pauses the first part of the actions and waits for the user to respond, and while waiting the delay timer of 200ms fires. Since your second reference to XMLHttpRequest() depends on the successful execution of the first execution of XMLHttpRequest(), the whole action secquence fails and nothing is written (or an "undefined" return from the server).
  
  So, the first solution would seem to be to just remove the Delay actions. WRONG.
  In each execution of the XMLHttpRequest() you have set the flag "nouser" which puts the function into asynchronous mode. This is a good thing because it means the browser will never hang waiting for the function to finish. However, your actions are based on a linear, or synchronous execution. Therefore, both XMLHttpRequests() will be made before a successful response is received from the first execution of XMLHttpRequest().
   
• Here is one successful approach. Make the sharedAction truly linear or synchronous rather than asynchronous.
  This only involves changing the "nouser" flag to false (the default) value.
  

  

  Make XMLHttpRequest() synchronous NOT asynchronous.

  POST Action.png (14.57 KiB) Viewed 1127 times

  
   
• A better solution would be to rewrite your PHP file(s) to receive both the path and file contents in the same POST request. This is better logistically. Then specify an object to receive the user event callback from XMLHttpRequest() and then alert the user if the server tasks fail for some reason. In this case, you should probably send the user event to name of self to keep things logical. This keeps your browser in asynchronous mode and sends the callback user event to the object (in this case a button) which initiated these actions. The user event value parameter will be set to whatever the server response data is; maybe 0 or a value greater than zero to reflect the number of bytes written which is what PHP would return from a successful call to write contents to a valid file.
  

  

  Optimize your multiple calls to XMLHttpRequest() into a single call.

  POST Action 2.png (14.8 KiB) Viewed 1127 times

  
  
  The user event code could be written something like this:
  

  on user event... (Paramters: value)
      if value = "somevalue"
          Display alert: "The server says all was successful." & crlf & "Number of bytes written: " & value
      else
          Display alert: "A problem occurred: " & value
      end if
  end user event

Please note that I made some of these adjustments and the folders and details.dat file was created and contained the base64 password. Please realize that if you intend this to be secure from prying eyes, then you should use 128 or 256 AES encryption. Even if you hard code the password to decrypt in your function call, it is very unlikely that someone is going to figure out what is going on and successfully break the system. And unless there was a lot of money to make on breaking the encryption, who would really want to spend time on this. There are other ingenius ways of embeddding decryption passwords on the server or inside the loaded TBK object inside the browser.
 

Hi Clifton,

Thank you for dealing with my problems so efficiently. You are very patient! I now know that I should not use media delays indiscriminately. Originally I put the delay in because the second XMLHttpRequest was not succeeding. I am not completely out of the woods yet because I still have to deal with the bad folder names but I suspect this may also be related to incorrect usage of media delays.

On a similar topic, I still help Carlo who uses TB 10 native to update his old programs made with TB 4.0. Lately we have discovered that on recent, fast computers the TB scripts do not always function correctly even though they contain no errors. The only solution we have found is to put pauses of 500 ms in steps etc. But this is a very blunt instrument! My misuse of media pauses stems from this experience.

I will use 128 encryption as it is safer but my main preoccupation was getting a system to actually store the password.

John

Thanks, it was useful.