Kaju self-updater talk (v.2.x)

  1. ‹ Older
  2. last week

    Alberto D

    Jul 11 Pre-Release Testers, Xojo Pro
    Edited last week

    Hi, I'm testing this but I was always getting "The kaju CLI is not available. Build it first.", even after I build the Admin CLI.

    I had to change (from 'Prepare Kaju.xojo_script) this:

    dim kaju as string = topLevelPath + "/Kaju\ Admin\ CLI/Builds\ \-\ Kaju\ Admin\ CLI.xojo_project/Mac\ OS\ X\ \(Intel\)/kaju/kaju"

    to this:

    dim kaju as string = topLevelPath + "/Kaju\ Admin\ CLI/Builds\ \-\ Kaju\ Admin\ CLI.xojo_project/OS\ X\ 64\ bit/kaju/kaju"

    I think the original line is for 32 bits.
    I checked the commits on GitHub and it looks like in May 1st there were some changes, I believe one of them is the change from 32 bit to 64 bit.

    So far, I was able to:

    • upload the test files to a server I manage
    • change the URL to this new site (it uses https and it works)
    • upload the test files to the server (auth directory) and create the .htaccess file needed for basic authentication with .htpasswd file
    • reduce the code from the demo and put the code in a menu About - Check Update

    Still a lot to test and learn.

  3. 6 days ago

    Alberto D

    Jul 13 Pre-Release Testers, Xojo Pro
    Edited 6 days ago

    I'm having trouble with some cached files. I made a mistake generating the UpdateInformation.html for an authenticated URL, but from that point on it looks like Kaju always loads this file, even when I remove the file from the server.

    I don't know if the problem is the server, my Mac or if there is some code that I need to change to make Kaju load the file again. When I use the browser I can see the new file or get a 404 (if I change the name).

    What I'm doing, is setting different names for the UpdateInformation.html file to do my testing.

    On another note: if I use a server with no SSL, I can click the button 'From URL' on Kaju Admin and the Hash is updated, but when I use a server with SSL (https) I always get "Could not get the executable from that url: 102"

    Edit: my problem with cached files is only with authenticated URLs (https://user:pass@example.com/kajutest_auth/) If I change the regular https URL I get a 404 error.

  4. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    I'm not sure what that's about as Kaju doesn't cache that file. Have you tried tracing through the code to see what url it's actually loading?

  5. Alberto D

    Jul 14 Pre-Release Testers, Xojo Pro

    Thank you Kem for looking into it. I was doing more tests and found this:

    When using Checker.ExecuteAsync, I have this problem, changing to Checker.Execute() solve the problem.

    I have 2 test files on the server, UpdateInfo.html and UpdateInformation.html both with 2 versions, UpdateInfo.html101 (is with a new version 1.0.1 file) and UpdateInfo.html102 (version 1.0.2), just to make sure changing files back will change the information shown.

    One button use Checker.Execute() and check UpdateInfo.html the other use Checker.ExecuteAsync and check UpdateInformation.html

    I change from 101 to 102 and Checker.Execute() will show 101 or 102 as I change the files. Checker.ExecuteAsync always show the same information.

    My URL is in like this: https://user:pass@server.com/kajutest_auth/

  6. Alberto D

    Jul 14 Pre-Release Testers, Xojo Pro
    Edited 6 days ago

    Kem, I used your demo to test this.

    • have UpdateInformation.html101 and UpdateInformation.html102
    • rename UpdateInformation.html101 to UpdateInformation.html
    • change the 'Asynchronous' check mark to use both options
    • both shown the 1.0.1 information
    • rename UpdateInformation.html102 to UpdateInformation.html
    • without the 'Asynchronous' check I get 1.0.2 information
    • using Asynchronous, still get 1.0.1 information

    screengrab:
    -image-

    Edit: I changed the URL information to not make public my actual server, username and password

  7. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    I have to believe this is server-side. Can you turn off caching in that directory?

  8. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Or can I set "no-cache" in the header of the requests to avoid caching?

  9. Tim P

    Jul 14 Pre-Release Testers, XDC Speakers

    @Kem T Or can I set "no-cache" in the header of the requests to avoid caching?

    I think that's a very good idea for the way this gets used :)

  10. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Will the server honor it though?

  11. Alberto D

    Jul 14 Pre-Release Testers, Xojo Pro

    I'll try to do that, but my question here will:
    if this is a cache issue and only affect the Asynchronous code, isn't there something on Xojo's side that will force the check?

    And other question:
    if cache is the issue, why all browsers behave correctly? As soon as I replace the 1.0.1 with 1.0.2 or back and reload the page, I get the correct information.

  12. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Once we get to the bottom of why it's happening, the answers to these questions might present themselves.

  13. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    With @Alberto D;Poo 's help, it's now resolved, and adding the request headers did it. The fix is now in the develop branch.

  14. Kem T

    Jul 14 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    HHTPSocketAsync.SetSecure now reads this way:

    Private Sub SetSecure(ByRef url As String)
      ValidateCertificates = true
      Username = ""
      Password = ""
      ClearRequestHeaders
      
      RequestHeader( "Cache-Control" ) = "private, no-cache, max-age=0"
      RequestHeader( "Pragma" ) = "no-cache"
      
      url = url.ConvertEncoding( Encodings.UTF8 )
      
      #if not TargetMacOS then
        
        //
        // See if the username and password has been specified
        //
        dim rx as new RegEx
        rx.SearchPattern = "^(https?://)([^:/\x20@]+):([^:/\x20@]*)@(.*)"
        
        dim match as RegExMatch = rx.Search( url )
        if match isa RegExMatch then
          Username = DecodeURLComponent( match.SubExpressionString( 2 ) ).DefineEncoding( Encodings.UTF8 )
          Password = DecodeURLComponent( match.SubExpressionString( 3 ) ).DefineEncoding( Encodings.UTF8 )
          url = match.SubExpressionString( 1 ) + match.SubExpressionString( 4 )
          url = url.DefineEncoding( Encodings.UTF8 )
          
          //
          // Set the request header manually
          //
          dim encoded as string = EncodeBase64( Username + ":" + Password ).DefineEncoding( Encodings.UTF8 )
          RequestHeader( "Authorization" ) = "Basic " + encoded.ToText
        end if
        
      #endif
    End Sub

    I added the second "Pragma" just in case, but the first "Cache-Control" by itself did the trick. As HTTP is not my forte, any other suggestions?

  15. 5 days ago

    Kem T

    Jul 15 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    I just added a public key override to the test app. You can now use it to test your own update files without having to change code.

    This is still in the develop branch.

  16. Kem T

    Jul 15 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    I've added two features, one of which I'd like feedback.

    The first is a security token added to the export. This is a random 8-byte token, Base64-encoded, that will be added to each version's info. This will ensure that each export of the information will have a different RSA signature and will not affect older versions of Kaju as it just ignores that field anyway.

    The second, the one that requires feedback, is compensation for different line endings. My concern is for those that open the export packet and end up saving it with different EOL characters. With that in mind, Kaju will try to validate the raw JSON string as-is and with the line endings replaced with each of the three possibilities until it finds it valid. The code looks like this:

    dim isValid as boolean
    
    dim eolChars() as string = array( "", &u0A, &u0D, &u0D + &u0A )
    for each eol as string in eolChars
      dim tester as string = raw
      if eol <> "" then
        tester = ReplaceLineEndings( tester, eol )
      end if
      
      isValid = Crypto.RSAVerifySignature( tester, sig, ServerPublicRSAKey )
      if isValid then
        exit for eol
      end if
    next
    
    if not isValid then
      return HandleError( KajuLocale.kErrorIncorrectPacketSignature )
    end if

    Good idea? Bad idea?

  17. 4 days ago

    A bit off here, but any reason why I would get the "This OS is not supported (missing required tools) message?" randomly?

    I had this working fine last week, with no issues at all... now, I get this message quite often.. not all the time, but it is enough to tell me Ive messed something up somewhere.

    If I go into the OSisSupported and delete this:

    #elseif TargetWindows then
      
      dim sh as new Shell
      sh.Execute "XCOPY /?"
      r = sh.ErrorCode = 0
      
    #else // Linux
      
      dim cmds() as string = array( "rsync --version", "/usr/bin/logger --version" )
      
      dim sh as new shell
      for each cmd as string in cmds
        sh.Execute cmd
        if sh.ErrorCode <> 0 then
          r = false
          exit
        end if
      next

    Then everything works great again.

    This is on a window machine, building for windows only

  18. Kem T

    Jul 16 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Deleting that code is not the answer because, if XCOPY is truly missing, the whole process will fail without warning. Instead, log the error code and result so we can get to the bottom of it.

    My guess is that it's a timing issue. I'll add a timeout, some logging, and perhaps a loop so it can try more than once.

  19. Tim P

    Jul 16 Pre-Release Testers, XDC Speakers

    I mean, removing code from the function OSisSupported seems like such a good idea.

  20. Kem T

    Jul 16 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    Be nice, Tim. :)

  21. Kem T

    Jul 16 Pre-Release Testers, Xojo Pro, XDC Speakers New York

    @kyle h I've pushed those changes out to the develop branch, please let me know what you find.

or Sign Up to reply!