I've got a problem with the user experience I want to design. Here's what should happen :
1. The user should always see the Wizard view for updates, and not the web page view
I've accordingly set the preferences to "Wizard" for Next Usage, Scheduled, End of Installation, and Manual under the User Interface tab.
2. I want the user to be authenticated
I have therefore setup the ASP page (copied and modified from the samples). I have also enabled Authentication, and am pointing my message to the ASP page.
Now here's what happens when I manually check for an update:
When the update message is active, the update is downloaded and installed without ever going to the authentication page.
Now, if I change the User Interface preferences to use "Web" then the authentication page comes up.
Does this mean I cannot authenticate if my user interface is not set to web ? How can I successfully authenticate with the Wizard interface selected ?
I understand your use case. Unfortunately, you have found a current limitation with our authentication feature - it currenlty only works in the web UI. In a future release, we will make authentication usable from the wizard UI. You will be able to set (via API) the user data. This data will be sent to the server without prompting.
Lets say I do change my UI to use the web interface temporarily until the Wizard interface supports authentication.
I set the authentication URL. Now, when the authentication module tries to call the given URL, it times out. This is because the ASP page is on an internal web server, not visible from the outside of the organization.
The externally visible web server is not a location where I would like to place my ASP page for authentication - mainly because I myself cannot publish to that web server, and would have to go through others for every change.
So how do I go about using the authentication feature at all ??
For customer who want to use authentication......the core issue is that only your systems know if the user can receive the update or not. We can't change that fact unless we start importing your customer data into the Update Service server - which is probably not a desirable thing.
That being said, you need to make the authentication routine accessible to the outside world (your customers). If it is a core business requirement to authenticate customers before allowing them to get updates, you should have internal support to publish the authentication routine to a server that can be accessed by the outside world.
I assume that that if the Wizard interface supports authentication, then because the Update agent would be running inside the organization firewall, the internal web server would be visible, and therefore authentication would work without having to publish the page externally.
OR
Am I wrong and will the Update Service at installshield call the authentication ASP page instead of the agent calling the authentication ASP page ? Therefore the ASP page would still need to be externally accessible ?
Also, is there a planned release/version/target date when authentication will be supported by the Wizard interface ?
Ahh. I think I see the confusion between us. I assumed that the users of your application were external users (not within your firewall). Most companies using Authentication are validating that external customers have paid for a support program before allowing them to get updates. But in your case, it sounds like they are internal to your company.
In answer to your questions, you are correct that the communication is between the Notification server and your server. That is done for security reasons. We don't want someone to sniff the traffic from the client to your authentication server. Having said that, I can see how that could cause you an issue if you are just deploying within your firewall.
I cannot give you a date for when Authentication will be supported in the wizard UI. But I will say that we are on 3-4 month release cycles. I hope to be adding that feature in the next release or two.
I think instead of asking about the authentication, I should tell you why I am trying to do this at all.
Our deployment scenario is something like this -
All users are inside our firewall. These users fall into different regions of the country. Usually, the release of our software is applicable to users in all regions. Once in a while, the release is applicable for users in a single region only.
I think it would be too cumbersome to define and publish seperate Products in Update Service for each region, mainly when they are all built off the same source etc and are usually applicable to all regions.
Therefore the way I planned to do this was to authenticate the user, and in the ASP authentication page, check whether the software release was relevant for the user's region. If yes, then return OK otherwise return FAILED.
If I did define seperate products in Update Service, I would need to maintain separate InstallShield Professional projects, and build and publish all of these identical products every time our software was updated.
Now, is there some other way I can do this or was using authentication the correct approach ?
