Visitor / Auto group - Revision history

Cg_pham at 05:05, 22 December 2011

2011-12-22T05:05:54Z

← Older revision		Revision as of 05:05, 22 December 2011
Line 1:		Line 1:
	~~[[Category:Site_resources]]~~		== Visitor / Auto group ==


	~~===~~Visitor ~~/ Auto group===~~		From version 5.5 Catglobe introduces a new way in which different Catglobe sites can work together and exchange information while still managing strict access validations. This new methodology is called "Visitor" and is initially only set up for web shop cooperation, but will from version 5.6 be extended with sample request enhancements between sites. The following file tries to explain the logic of the "Visitor" feature and how you must set it up to work correctly between sites.

	From version 5.5 Catglobe introduces a new way in which different Catglobe sites can work together and exchange information while still managing strict access validations. This new methodology is called "Visitor" and is initially only set up for web shop cooperation, but will ~~from version 5.6~~ be ~~extended with sample request enhancements~~ between sites~~. The following file tries to explain the logic of the "Visitor" feature and~~ how ~~you must set it up~~ to ~~work correctly between sites~~.		Since we will be discussing the process between two sites, let us first define clearly how to understand these.

	~~Since we will be discussing the process between two sites, let us first define clearly how to understand these~~.		'''Main site: '''The site that you as a user come from.

	'''~~Main~~ site: '''The site that you as a user ~~come~~ from.		'''External site: '''The site that you as a user will visit and collect/view data from.

	~~'''External~~ site: ~~'''The site that you as a user will visit and collect/view data from.~~		To be able to visit an external site, there needs to be defined an identical code on both the main and external site which helps tell:

	~~To be able to visit an external~~ site~~, there needs to be defined an identical code on both the main and external site which helps tell:~~		1. What site you are visiting from.

	1. What site you are visiting ~~from~~.		2. What access you should be given on the site you are visiting.

	~~2. What access you should be given~~ on the site you ~~are~~ visiting.		Now let us pretend that we are an administrator on the external site and want to specify what you as a visitor from the main site will get in terms of access when visiting. Go to the site list and open the main site dialog. You will see that is has a tab called "auto-group". Try to add one of these.

	~~Now let us pretend that we are an administrator on the external site and want to specify what you as a visitor from the main site will get in terms of access when visiting~~. ~~Go to the site list and open the main site dialog. You will see that is has a tab called "auto~~-~~group". Try to add one of these.~~		[[Image:5830.png\|714px\|SIte56-2]]

	~~[[Image:5830~~.~~png\|714px\|SIte56~~-~~2]]~~		An auto-group is a group a visitor will become member of given the fact that he knows the related code. Since these codes are initially made on the external site, then a code will automatically be proposed once you choose to add an auto-group. Where and how the code will be used on the main site depends on which module will exchange visitors. This will be shown in more detail later.

	An auto-group ~~is a group a visitor will become member of given~~ the ~~fact that he knows~~ the ~~related code. Since these codes are initially made on~~ the ~~external~~ site, then ~~a code~~ will ~~automatically~~ be ~~proposed once you choose~~ to ~~add an auto-group. Where and how~~ the ~~code will be used on~~ the main site ~~depends on~~ which ~~module will exchange visitors. This~~ will be ~~shown~~ in ~~more~~ detail ~~later~~.		Once the auto-group has been set up on the external site and the main site has implemented the site information and set up the visitor code, then the first visitors will be ready to take the trip from the main site to the external site. The way in which it will be initiated is solely based on what module the visitor comes from, but the way in which he is treated on the external site is very similar from time to time, so this process is explained in detail below.

	~~Once~~ the ~~auto-group has been set up~~ on the external site ~~and~~ the ~~main~~ site ~~has implemented~~ the ~~site information and set up~~ the ~~visitor~~ code, then the ~~first visitors~~ will be ~~ready to take the trip from~~ the ~~main site to~~ the ~~external site~~. The ~~way in~~ which ~~it will be initiated~~ is ~~solely based on~~ what ~~module the~~ visitor ~~comes from, but the way in which he is treated on~~ the external site ~~is very similar from time to time~~, so this ~~process~~ is ~~explained in detail below~~.		When a visitor visits an external site, he will initially need to go though the security gates of the external site. The main site will help with this by sending the code that it knows exists on the external site to the security gate. If the external site acknowledges the existence of the code, then the visitor will be let through the security gate into the user registration area. The users of Catglobe all have a personal identification number, which is unique no matter what site they come from. The visitor will hand this over to the external site, who will see if this visitor is already registered there.

	~~When a visitor visits an~~ external site~~, he~~ will ~~initially need to go though~~ the ~~security gates of the external~~ site. The ~~main~~ site will ~~help~~ with ~~this by sending~~ the ~~code~~ that ~~it knows exists on the external site~~ to the ~~security gate~~. If the external site ~~acknowledges the existence of the code, then the visitor~~ will ~~be let through the security gate into~~ the user registration ~~area. The users of Catglobe all have a personal identification number~~, which is ~~unique no matter what~~ site ~~they come~~ from. ~~The visitor will hand~~ this ~~over to~~ the ~~external site, who will see if this visitor is already registered there~~.		If the user is not yet registered, then the external site will ask for more personal information about this user from the main site, like full name, address, e-mail, phone numbers and so on. The external site will then register this information together with the visitors unique id, so that he will not need to be registered again the next time he visits. Since the external site will need to decide on which role (resource template) that the user should get upon registration, the system will look at which resource template is specified for this purpose on the site from which the visitor comes. You can see where to register this in the screen example above.

	If the user is ~~not yet~~ registered, then the external site will ~~ask for more personal information about this user from~~ the main site, ~~like full name, address, e-mail, phone numbers and so on~~. ~~The external site~~ will ~~then register~~ this information ~~together with~~ the ~~visitors unique id, so that he will not need to be registered again the next time he visits. Since the external~~ site ~~will need~~ to ~~decide on which role (resource template) that~~ the ~~user should get upon registration, the system will look at which resource template is specified for this purpose~~ on the site ~~from which the visitor comes. You can see where to register this in the screen example above~~.		If the user is already registered, then the external site will check with the main site, if any personal information has changed. If it has then it will update this information from the main site to the account on the external site.

	If the ~~user~~ is ~~already registered~~, ~~then~~ the ~~external site~~ will ~~check with~~ the main site~~, if any personal information has changed~~. If it has then it will ~~update~~ this ~~information from the main site to the account on the external site~~.		Third step is to check whether or not the visitor is associated with the Auto-Group for which he used the code to get through the security gate. Users from external sites may enter with many different codes, since the codes will directly be related to a module on the main site. If he enters with a code he has never before used, then we will see what group is related to this code and make sure he becomes a member of it.

	~~Third step is to check whether or not~~ the ~~visitor~~ is ~~associated with~~ the ~~Auto-Group for which he used~~ the ~~code to get through~~ the ~~security gate. Users from external sites may enter~~ with ~~many different codes, since the codes will directly be related~~ to ~~a module~~ on ~~the main~~ site~~. If he enters with a code he has never before used~~, ~~then we will see what~~ group ~~is related to this code and make sure he becomes a member of it~~.		Once we make him a member of this group he will thus get the resource and navigation rights of it. It is therefore important that the administrator of the external site decides specifically what the visitors entering with that code are allowed to do and see on his site, and thus set up the related group with those exact access rights.

	~~Once we make him~~ a ~~member~~ of ~~this group he will thus get~~ the ~~resource and navigation rights of it. It is therefore important that the administrator of~~ the ~~external site decides specifically what the visitors entering with that code are allowed to do and see~~ on ~~his site, and thus set up~~ the ~~related group with those exact access rights~~.		For a more concrete example of how the visitor feature works, please refer to the help file on the '[[Web shop visitor\|web shop visitor]]'. __NOTOC__ <!-- imported from file: 5435.htm-->

	~~For a more concrete example of how the visitor feature works, please refer to the help file on the '~~[[~~_Web_shop_visitor_\|web shop visitor~~]]'.		[[Category:Site_resources]]
	~~__NOTOC__~~
	~~<!-- imported from file: 5435.htm-->~~

Cg van at 03:23, 12 May 2011

2011-05-12T03:23:35Z

← Older revision		Revision as of 03:23, 12 May 2011
Line 1:		Line 1:
	[[Category:~~HelpBooks~~]]		[[Category:Site_resources]]

Catglobe: jrfconvert import

2011-03-07T09:02:28Z

jrfconvert import

New page

[[Category:HelpBooks]]

===Visitor / Auto group===

From version 5.5 Catglobe introduces a new way in which different Catglobe sites can work together and exchange information while still managing strict access validations. This new methodology is called "Visitor" and is initially only set up for web shop cooperation, but will from version 5.6 be extended with sample request enhancements between sites. The following file tries to explain the logic of the "Visitor" feature and how you must set it up to work correctly between sites.

Since we will be discussing the process between two sites, let us first define clearly how to understand these.

'''Main site: '''The site that you as a user come from.

'''External site: '''The site that you as a user will visit and collect/view data from.

To be able to visit an external site, there needs to be defined an identical code on both the main and external site which helps tell:

1. What site you are visiting from.

2. What access you should be given on the site you are visiting.

Now let us pretend that we are an administrator on the external site and want to specify what you as a visitor from the main site will get in terms of access when visiting. Go to the site list and open the main site dialog. You will see that is has a tab called "auto-group". Try to add one of these.

[[Image:5830.png|714px|SIte56-2]]

An auto-group is a group a visitor will become member of given the fact that he knows the related code. Since these codes are initially made on the external site, then a code will automatically be proposed once you choose to add an auto-group. Where and how the code will be used on the main site depends on which module will exchange visitors. This will be shown in more detail later.

Once the auto-group has been set up on the external site and the main site has implemented the site information and set up the visitor code, then the first visitors will be ready to take the trip from the main site to the external site. The way in which it will be initiated is solely based on what module the visitor comes from, but the way in which he is treated on the external site is very similar from time to time, so this process is explained in detail below.

When a visitor visits an external site, he will initially need to go though the security gates of the external site. The main site will help with this by sending the code that it knows exists on the external site to the security gate. If the external site acknowledges the existence of the code, then the visitor will be let through the security gate into the user registration area. The users of Catglobe all have a personal identification number, which is unique no matter what site they come from. The visitor will hand this over to the external site, who will see if this visitor is already registered there.

If the user is not yet registered, then the external site will ask for more personal information about this user from the main site, like full name, address, e-mail, phone numbers and so on. The external site will then register this information together with the visitors unique id, so that he will not need to be registered again the next time he visits. Since the external site will need to decide on which role (resource template) that the user should get upon registration, the system will look at which resource template is specified for this purpose on the site from which the visitor comes. You can see where to register this in the screen example above.

If the user is already registered, then the external site will check with the main site, if any personal information has changed. If it has then it will update this information from the main site to the account on the external site.

Third step is to check whether or not the visitor is associated with the Auto-Group for which he used the code to get through the security gate. Users from external sites may enter with many different codes, since the codes will directly be related to a module on the main site. If he enters with a code he has never before used, then we will see what group is related to this code and make sure he becomes a member of it.

Once we make him a member of this group he will thus get the resource and navigation rights of it. It is therefore important that the administrator of the external site decides specifically what the visitors entering with that code are allowed to do and see on his site, and thus set up the related group with those exact access rights.

For a more concrete example of how the visitor feature works, please refer to the help file on the '[[_Web_shop_visitor_|web shop visitor]]'.
__NOTOC__