v.1.3.1 posted. If you’ve used the MinimumRequiredVersion field, just open your project in the new Admin app, repopulate that field, and publish the update information again.
@Sascha S , I found the problem here. I forgot that the ProgressBar has a max. That fix will be in the next release.
I just posted v.1.3.2. This fixes a few bugs in the Admin app and corrects the progress bar display issue.
Thank you @Kem Tekinay
I just posted v.1.3.3 to correct a bug that appeared after I introduced support for the “version (build)” form of the version. Basically, the release version wasn’t being converted to double properly.
As an informal survey, how many need Kaju to be able to get its update information and/or downloads from an authenticated web server?
what do you mean by authenticated web server?
When you access the link, you are required to enter a username and password.
ahh. then yes it would be nice to have but not a “hard requirement”.
At this point, we have no requirement for this.
Under what conditions would that be desirable? I can’t think of any.
Has anyone else run into this? When running a project containing Kaju in the debugger, with PROFILING turned ON, the debugger always encounters a NilObjectException in the destructor of the updater object when the application being debugged is quit. It looks like the object itself is NIL at the point its destructor is called.
It’s not a bug deal when running the IDE on the same machine; simply resuming works. But when running in a remote debugger session, no profiling data are saved.
I don’t recall ever having seen a similar condition in which the destructor of a nil object is invoked.
Very nice work Kem!
The only reason I can think of is if you are limiting updates to paid support contracts.
It’s probably never desirable, but a poorly designed mod_security might lead to someone being confused and having the issue.
It seems like there are better ways to handle that, but perhaps I haven’t dwelled on it enough.
I’m talking about this as an intentional design.
The reason I asked is because the provider for one of my clients has moved the server that will host their updates to an authenticated page. This presents a problem in that I now have to provide that authentication through code, but that sort of defeats the security since the username and password will have to be embedded in the code, or it will defeat the convenience since the user will have to enter it. Either way, I’m trying to figure out what the general desirability of this “feature” would be.
[quote=166650:@Peter Truskier]Has anyone else run into this? When running a project containing Kaju in the debugger, with PROFILING turned ON, the debugger always encounters a NilObjectException in the destructor of the updater object when the application being debugged is quit. It looks like the object itself is NIL at the point its destructor is called.
It’s not a bug deal when running the IDE on the same machine; simply resuming works. But when running in a remote debugger session, no profiling data are saved.
I don’t recall ever having seen a similar condition in which the destructor of a nil object is invoked.[/quote]
I just tried to reproduce this using the Test App and remote debugging to a Windows 7 VM, but cannot. The Profile is saved as a separate file (readable, btw, with my Profile Reader) and seems complete. I do not get an error of any sort even if I tell it to update.
Oh I agree. I was just trying to come up with something that might charitably be called a reason.
This was my solution. Please tell me if you see a flaw.
I already use a HTTPSecureSocket subclass to make the connections, so I created a property in UpdateChecker, Socket As Kaju.HTTPSSocket. You can subclass a HTTPSSocket and give it to UpdateChecker to use if you really want fine control over the process. I’m imagining cases where certificates and the like may be needed.
If you don’t do that, Get And GetHeaders, through the private SetSecure method, parse the given url with the following RegEx:
"^(?:https?://)([^:/\\x20@]+):([^:/\\x20@]*)@(.*)"If it finds a match, it sets the private properties Username and Password to SubExpressionString( 1 ) and ( 2 ), then “fixes” the url to SubExpressionString( 3 ). For example, if the url is given as “http://name:password@www.example.com”, it will put “name” into Username, “password” into Password, and make the url “www.example.com”.
Next, HTTPSSocket implements AuthenticationRequired like this:
Function AuthenticationRequired(Realm As String, Headers As InternetHeaders, ByRef Name As String, ByRef Password As String) As Boolean
if RaiseEvent AuthenticationRequired( Realm, Headers, Name, Password ) then
return true
end if
if Username <> "" then
Name = Username
Password = self.Password
return true
else
return false
end if
End FunctionThe upshot is that you can specify your urls in the form “http://un:pw@myurl.com” for the update information and/or the files, and it should just work.
Opinions?
Actually, I have to rethink the “Socket” property. The problem is that the download window won’t use it, so forget that part. The next version will not let you supply your own HTTPSSocket, but the rest of the changes need review.