VISTA Auto Signon - Revision history

Shabiel: /* How does Auto Sign-on Work */

2011-06-09T12:33:02Z

How does Auto Sign-on Work

← Older revision		Revision as of 12:33, 9 June 2011
Line 159:		Line 159:
	\|}		\|}

	What about sign-ons using ^ZU? They make the same sequence of events~~, although I am not sure on where in the code everything happens~~.
			In the M code, <code>LOG^XUS1</code> is called following a sign-on to 'create' the log-in cookie.

			What about sign-ons using ^ZU? They make the same sequence of events.

Shabiel at 12:33, 8 June 2011

2011-06-08T12:33:12Z

← Older revision		Revision as of 12:33, 8 June 2011
Line 110:		Line 110:
	</pre>		</pre>
	=== How does Auto Sign-on Work ===		=== How does Auto Sign-on Work ===
	When you try to sign-on to VISTA applications that support SSO, they will make a call from the server side to the client side on port 9200, where the client agent is listening. So, let's say your CPRS is signing on. ~~In the~~ 3rd RPC it sends is <code>XUS SIGNON SETUP</code>. This RPC will do a call back to the client running CPRS on port 9200 if SSO is running. If it gets a connection (isn't refused by the machine or blocked by firewalls), it will send a message to the client called <code>XWB GET HANDLE</code>. The client will reply back with <code>XWB QUERY RESPONSE</code>, to tell the server whether a handle has already been created for a previous application that logged on using an access and verify code.		When you try to sign-on to VISTA applications that support SSO, they will make a call from the server side to the client side on port 9200, where the client agent is listening. So, let's say your CPRS is signing on. The 3rd RPC it sends is <code>XUS SIGNON SETUP</code>. This RPC will do a call back to the client running CPRS on port 9200 if SSO is running. If it gets a connection (isn't refused by the machine or blocked by firewalls), it will send a message to the client called <code>XWB GET HANDLE</code>. The client will reply back with <code>XWB QUERY RESPONSE</code>, to tell the server whether a handle has already been created for a previous application that logged on using an access and verify code. If the server decides that the handle is valid, it will call the client with <code>XWB CREATE HANDLE</code>.

	Here is an example of server callback when nobody else has connected before:		Here is an example of server callback when nobody else has connected before:
Line 117:		Line 117:
	</pre>		</pre>

	Here is an example of server callback when somebody has connected before:		Here is an example of server callback when somebody has connected before (2 separate calls):
	<pre>		<pre>
	{XWB}000051117800015XWB GET HANDLES00000.{XWB}000051117800018XWB QUERY RESPONSE0000813766580.		{XWB}000051117800015XWB GET HANDLES00000.{XWB}000051117800018XWB QUERY RESPONSE0000813766580.
			{XWB}000051064200017XWB CREATE HANDLE00027HABIEL,SAM M^3110608.132432.{XWB}000051064200018XWB QUERY RESPONSE0000811970625.
	</pre>		</pre>

			The output of fifth subscript of the call <code>XUS SIGNON SETUP</code> is 0 or 1. If it is 1, then Single Signon succeeded, and the server can continue without authenticating the user again.

	What if the user has not signed on before and an access and verify code need to be entered? In that case, the server makes the following call to the client machine after the client has authenticated using the RPC <code>XUS AV CODE</code>:		What if the user has not signed on before and an access and verify code need to be entered? In that case, the server makes the following call to the client machine after the client has authenticated using the RPC <code>XUS AV CODE</code>:
Line 136:		Line 139:
	</pre>		</pre>

			There is one last case scenario which we need to consider.

	Here's a summary:		Here's a summary:
Line 156:		Line 159:
	\|}		\|}

	What about sign-ons using ^ZU? They make the same sequence of events, although I am ~~less clearer~~ on where in the code everything happens.		What about sign-ons using ^ZU? They make the same sequence of events, although I am not sure on where in the code everything happens.

Shabiel at 12:25, 8 June 2011

2011-06-08T12:25:38Z

← Older revision		Revision as of 12:25, 8 June 2011
Line 135:		Line 135:
	{XWB}000051064200017XWB DELETE HANDLE0000811970625.{XWB}000051064200018XWB QUERY RESPONSE00007DELETED.		{XWB}000051064200017XWB DELETE HANDLE0000811970625.{XWB}000051064200018XWB QUERY RESPONSE00007DELETED.
	</pre>		</pre>



	Here's a summary:		Here's a summary:
Line 142:		Line 144:
	\|-		\|-
	\|XUS SIGNON SETUP		\|XUS SIGNON SETUP
	\|XWB GET HANDLE		\|XWB GET HANDLE (& XWB CREATE HANDLE if SSO'ed)
	\|XWB QUERY RESPONSE		\|XWB QUERY RESPONSE
	\|-		\|-
	\|XUS AV CODE		\|XUS AV CODE (doesn't take place if SSO'ed)
	\|XWB CREATE HANDLE		\|XWB CREATE HANDLE
	\|XWB QUERY RESPONSE		\|XWB QUERY RESPONSE

Shabiel at 11:47, 8 June 2011

2011-06-08T11:47:26Z

← Older revision		Revision as of 11:47, 8 June 2011
Line 153:		Line 153:
	\|XWB QUERY RESPONSE		\|XWB QUERY RESPONSE
	\|}		\|}

			What about sign-ons using ^ZU? They make the same sequence of events, although I am less clearer on where in the code everything happens.

Shabiel at 11:43, 8 June 2011

2011-06-08T11:43:45Z

← Older revision		Revision as of 11:43, 8 June 2011
Line 137:		Line 137:

	Here's a summary:		Here's a summary:
	{\| border="1"		{\| border="1" cellpadding="2"
	\|+ Auto-signon server calls vs client RPCs		\|+ Auto-signon server calls vs client RPCs
	! Client RPC Call !! Server Callback for SSO !! Client Reply for SSO		! Client RPC Call !! Server Callback for SSO !! Client Reply for SSO

Shabiel at 11:42, 8 June 2011

2011-06-08T11:42:35Z

← Older revision		Revision as of 11:42, 8 June 2011
Line 139:		Line 139:
	{\| border="1"		{\| border="1"
	\|+ Auto-signon server calls vs client RPCs		\|+ Auto-signon server calls vs client RPCs
	! ~~Column heading 1~~ !! ~~Column heading 2~~ !! ~~Column heading 3~~		! Client RPC Call !! Server Callback for SSO !! Client Reply for SSO
	\|-		\|-
	\|~~Cell 1~~ \|\| ~~Cell 2 \|\| Cell 3~~		\|XUS SIGNON SETUP
			\|XWB GET HANDLE
			\|XWB QUERY RESPONSE
	\|-		\|-
	\|~~Cell A~~		\|XUS AV CODE
	\|~~Cell B~~		\|XWB CREATE HANDLE
	\|~~Cell C~~		\|XWB QUERY RESPONSE
			\|-
			\|#BYE#
			\|XWB DELETE HANDLE
			\|XWB QUERY RESPONSE
	\|}		\|}

Shabiel at 11:39, 8 June 2011

2011-06-08T11:39:12Z

← Older revision		Revision as of 11:39, 8 June 2011
Line 137:		Line 137:

	Here's a summary:		Here's a summary:
	{\|		{\| border="1"
	\|+ Auto-signon server calls vs client RPCs		\|+ Auto-signon server calls vs client RPCs
	! Column heading 1 !! Column heading 2 !! Column heading 3		! Column heading 1 !! Column heading 2 !! Column heading 3

Shabiel at 11:38, 8 June 2011

2011-06-08T11:38:30Z

@@ Line 128: / Line 128: @@
 </pre>
-Once this is executed, the client has a handle which it can supply to the server when it is queried using <pre>XWB GET HANDLE</pre>. If that handle is supplied, the server will check it in the ^XUSEC(0) global to see if it is valid. If it is, we can auto-sign on the user.
+Once this is executed, the client has a handle which it can supply to the server when it is queried using <code>XWB GET HANDLE</code>. If that handle is supplied, the server will check it in the ^XUSEC(0) global to see if it is valid. If it is, we can auto-sign on the user.
 Let's look at the other end of the loop: When the client says <code>#BYE#</code> to the RPC Broker, XWB code deletes the handle by calling back the client as follows:
@@ Line 135: / Line 135: @@
 {XWB}000051064200017XWB DELETE HANDLE0000811970625.{XWB}000051064200018XWB QUERY RESPONSE00007DELETED.
 </pre>

Shabiel at 11:34, 8 June 2011

2011-06-08T11:34:30Z

← Older revision		Revision as of 11:34, 8 June 2011
Line 16:		Line 16:
	Once you run clagent.exe, you will see the image of a little satellite dish in your system tray.		Once you run clagent.exe, you will see the image of a little satellite dish in your system tray.

	Once you sign-on (first sign-on is required) using roll and scroll or any client, the satellite lights up. It means that you are signed into VISTA. Any subsequent sign-on in a client that supports it (not Scheduling ~~or PIM GUI~~ at the moment) will auto-sign you in.		Once you sign-on (first sign-on is required) using roll and scroll or any client, the satellite lights up. It means that you are signed into VISTA. Any subsequent sign-on in a client that supports it (not Scheduling at the moment) will auto-sign you in.

	In order to auto-sign on a user, you need to call the [[RPC]] named [[XUS SIGNON SETUP]], and check the return value of subscript 5 and see if it is 1. If it is, then Auto-Sign on succeeded.		In order to auto-sign on a user, you need to call the [[RPC]] named [[XUS SIGNON SETUP]], and check the return value of subscript 5 and see if it is 1. If it is, then Auto-Sign on succeeded.
Line 110:		Line 110:
	</pre>		</pre>
	=== How does Auto Sign-on Work ===		=== How does Auto Sign-on Work ===
	When you try to sign-on to VISTA applications that support SSO, they will make a call from the server side to the client side on port 9200, where the client agent is listening. So, let's say your CPRS is signing on. In the ~~second~~ RPC it sends is <code>XUS SIGNON SETUP</code>. This RPC will do a call back to the client running CPRS on port 9200. If it gets a connection (isn't refused by the machine or blocked by firewalls), it will send a message to the client called <code>XWB GET HANDLE</code>. The client will reply back with <code>XWB QUERY RESPONSE</code>, to tell the server whether a handle has already been created for a previous application that logged on using an access and verify code.		When you try to sign-on to VISTA applications that support SSO, they will make a call from the server side to the client side on port 9200, where the client agent is listening. So, let's say your CPRS is signing on. In the 3rd RPC it sends is <code>XUS SIGNON SETUP</code>. This RPC will do a call back to the client running CPRS on port 9200 if SSO is running. If it gets a connection (isn't refused by the machine or blocked by firewalls), it will send a message to the client called <code>XWB GET HANDLE</code>. The client will reply back with <code>XWB QUERY RESPONSE</code>, to tell the server whether a handle has already been created for a previous application that logged on using an access and verify code.

	Here is an example of ~~CPRS~~ server callback when nobody else has connected before:		Here is an example of server callback when nobody else has connected before:
	<pre>		<pre>
	{XWB}000051064200015XWB GET HANDLES00000.{XWB}000051064200018XWB QUERY RESPONSE00000.		{XWB}000051064200015XWB GET HANDLES00000.{XWB}000051064200018XWB QUERY RESPONSE00000.
	</pre>		</pre>

	Here is an example of ~~CPRS~~ server callback when somebody has connected before:		Here is an example of server callback when somebody has connected before:
	<pre>		<pre>
	{XWB}000051117800015XWB GET HANDLES00000.{XWB}000051117800018XWB QUERY RESPONSE0000813766580.		{XWB}000051117800015XWB GET HANDLES00000.{XWB}000051117800018XWB QUERY RESPONSE0000813766580.
			</pre>

			What if the user has not signed on before and an access and verify code need to be entered? In that case, the server makes the following call to the client machine after the client has authenticated using the RPC <code>XUS AV CODE</code>:

			<pre>
			{XWB}000051064200017XWB CREATE HANDLE00027HABIEL,SAM M^3110608.132432.{XWB}000051064200018XWB QUERY RESPONSE0000811970625.
			</pre>

			Once this is executed, the client has a handle which it can supply to the server when it is queried using <pre>XWB GET HANDLE</pre>. If that handle is supplied, the server will check it in the ^XUSEC(0) global to see if it is valid. If it is, we can auto-sign on the user.

			Let's look at the other end of the loop: When the client says <code>#BYE#</code> to the RPC Broker, XWB code deletes the handle by calling back the client as follows:

			<pre>
			{XWB}000051064200017XWB DELETE HANDLE0000811970625.{XWB}000051064200018XWB QUERY RESPONSE00007DELETED.
	</pre>		</pre>

Shabiel at 11:19, 8 June 2011

2011-06-08T11:19:26Z

@@ Line 1: / Line 1: @@
-VISTA Auto Sign-on that doesn't rely on [[CCOW]] can be accomplished as follows:
+=== Setting Up VISTA Auto Sign-on ===
 You need to have the RPC Client Agent running on your machine. You can get this from this set-up program here:
@@ Line 107: / Line 108: @@
    end;
 end;
 </pre>