Can web update handle the <setup>.exe behind a login?

[JohnO]

The value for the URL of the setup.exe in the updates.ini file is like:

Code: Select all

https://support.myco.com/downloads/MyApp2.1.2.exe

If I type this into a browser, I get the Login page. I then enter the: id, pswd and capcha. This produces the 'do you want to save or run' prompt for the exe.

Is it possible to customise the 'updates' script to handle this login interruption? If it ought to be possible, could you give me some guidance as to what I need to do and where in the script?

FYI, with the default code in the 'update' script, after pressing Download on the 'Choose updates to download' dialog, the Install dialog has an empty Update Title field. Pressing Install, causes a prompt to appear asking me to select some updates, and then I am taken back to the Download dialog. This goes on ad infinitum, until I press Cancel.

John

[FrancescoT]

Dear John,

Unfortunately, it is not possible to pass login credentials with the URL.

This is not an IA limitation but a security rule introduced by Microsoft ... this argument has been widely discussed with our forum ( ... just do a search).

Regarding your other question, honestly I suspect that probably exist something wrong with your script.
I can possibly verify it only, if you supply a test project that replicates the issue.

Regards

[JohnO]

Dear Francesco
Thanks for clarifying that. I was hoping that some clever changes to the 'updates' script might work, or that there was a plugin.

I need to eliminate solutions that might avoid me having to create a more involved RYO checking-solution for our Eclipse app to do at startup. It looks like I may have to use an approach of putting a password on the setup.exe and making that password available from our support site (instead of the setup.exe).

As long as my Java code can find updates.ini on our web server (I can) and installedupdates.dat locally (not yet), I should be able to figure out if there are any updates for the current version.

John

BTW. The 'updates' script was unchanged apart from the addition of some MsgBoxes for debug. I only described the behaviour, in case it looked like what you would expect when the download fails due to a userid/pswd challenge. It's not an issue as I can't go down that route.