Difference between revisions of "RPC HELP Silent Login"
| Line 3: | Line 3: | ||
[[RPC_Broker_Silent_Login_Example|Example]] | [[RPC_Broker_Silent_Login_Example|Example]] | ||
| − | Silent Login is a way to log in a user with known login information. Silent Login skips the step of asking the user for login information. It is similar to Auto Signon in some ways, but there are important differences. | + | The RPC Broker provides "Silent Login" capability. Silent Login is a way to log in a user with known login information. Silent Login skips the step of asking the user for login information. It provides functionality associated with the ability to make logins to a VistA M Server without the RPC Broker asking for Access and Verify code information. It is similar to Auto Signon in some ways, but there are important differences. |
| + | |||
| + | There are two types of Silent Login are provided with the RPC Broker 1.1 BDK: | ||
| + | |||
| + | * '''Access/Verify Code-based''' — Type of Silent Login that uses Access and Verify codes provided by the application. This type of Silent Login may be necessary for an application that runs as a background task and repeatedly signs on for short periods. Another case would be for applications that are interactive with the user, but are running under conditions where they cannot provide a standard dialogue window, such as that used by the Broker to request Access and Verify codes. Examples might be applications running on handheld devices or within a browser window. | ||
| + | * '''Token-based''' — Type of Silent Login that uses a token obtained by one application that is passed along with other information as a command line argument to a second application that it is starting. The token is obtained from the VistA server and remains valid for about twenty (20) seconds. When the newly started application sends this token during login the server identifies the same user and completes the login. | ||
| + | |||
| + | Due to the various conditions under which Silent Logins might be used, it was also necessary to provide options to the applications on error handling and processing. Applications that run as system services crash if they attempt to show a dialogue box. Similarly, applications running within Web browsers are not permitted to show a dialogue box or to accept windows messages. Properties have been provided to permit the application to handle errors in a number of ways. | ||
| + | |||
| + | As a part of the Silent Login functionality, the [[RPC_HELP_TVistaUser|TVistaUser]] Class providing basic user information was added. This class is used as a property by the [[RPC_HELP_TRPCBroker|TRPCBroker]] class and is filled with data following completion of the login process. This property and its associated data is available to all applications, whether or not they are using a Silent Login. | ||
| + | |||
| + | Note: For more information on handling divisions during Silent Login, see [[RPC_HELP_Silent_Login_Handling Divisions|Handling Divisions During Silent Login]]. | ||
<H3>Silent Login Compared to Auto Signon</h3> | <H3>Silent Login Compared to Auto Signon</h3> | ||
Latest revision as of 17:04, 21 July 2015
Silent Login
The RPC Broker provides "Silent Login" capability. Silent Login is a way to log in a user with known login information. Silent Login skips the step of asking the user for login information. It provides functionality associated with the ability to make logins to a VistA M Server without the RPC Broker asking for Access and Verify code information. It is similar to Auto Signon in some ways, but there are important differences.
There are two types of Silent Login are provided with the RPC Broker 1.1 BDK:
- Access/Verify Code-based — Type of Silent Login that uses Access and Verify codes provided by the application. This type of Silent Login may be necessary for an application that runs as a background task and repeatedly signs on for short periods. Another case would be for applications that are interactive with the user, but are running under conditions where they cannot provide a standard dialogue window, such as that used by the Broker to request Access and Verify codes. Examples might be applications running on handheld devices or within a browser window.
- Token-based — Type of Silent Login that uses a token obtained by one application that is passed along with other information as a command line argument to a second application that it is starting. The token is obtained from the VistA server and remains valid for about twenty (20) seconds. When the newly started application sends this token during login the server identifies the same user and completes the login.
Due to the various conditions under which Silent Logins might be used, it was also necessary to provide options to the applications on error handling and processing. Applications that run as system services crash if they attempt to show a dialogue box. Similarly, applications running within Web browsers are not permitted to show a dialogue box or to accept windows messages. Properties have been provided to permit the application to handle errors in a number of ways.
As a part of the Silent Login functionality, the TVistaUser Class providing basic user information was added. This class is used as a property by the TRPCBroker class and is filled with data following completion of the login process. This property and its associated data is available to all applications, whether or not they are using a Silent Login.
Note: For more information on handling divisions during Silent Login, see Handling Divisions During Silent Login.
Silent Login Compared to Auto Signon
In Auto Signon, the Client Agent manages the login process on the client. On a primary login (i.e., no existing connections), the user is prompted for Access and Verify codes. On secondary logins, the Client Agent handles the login with the information from the primary login. Developers do not have access to the Auto Signon process.
NOTE: For more information on Auto Signon, see the "RPC Broker Systems Manual."
Silent Login offers developers an opportunity to skip the login process for the user if they have access to login information from some other source. It is up to the developer to deliver the appropriate login information to the application and enable the Silent Login process.
Interaction Between Silent Login and Auto Signon
On primary login, Silent Login happens if it is enabled (the KernelLogIn property is set to False and the AccessCode, VerifyCode and Mode properties of the LogIn property are set or the AppHandle and Mode properties are set). On secondary logins, the Client Agent, if enabled, handles the login and the Silent Login is bypassed. In other words, if there already is a connection and the Client Agent is enabled, the Silent Login information is not used.
NOTE: The "XUS SIGNON SETUP" RPC is called before a normal login or a Silent Login and if it identifies the user via Client Agent at the IP address, that identification is used to log the user in.
