
			<p><b>Dissemino Users and Subscribers</b></p>
			<p>When a registered user logs on, there will be a cookie and session in ALL cases. Although Dissemino allows upto 30 different classes of user, all users belong to
the subscriber class and authenticate against the subscriber repository. The subscriber class is an in-built class comprising the following member:-</p>
			<table> 
				<tr><td>1) userName </td><td>DATATYPE_STRING</td><td>Used to ensure usernames are unique across all user classes.</td></tr> 
				<tr><td>2) userEmail</td><td>DATATYPE_EMADDR</td><td>The email address of the subscriber. Can be used as an alternative to username.</td></tr> 
				<tr><td>3) userPass </td><td>DATATYPE_STRING</td><td>The user password.</td></tr> 
				<tr><td>4) regDate  </td><td>DATATYPE_SDATE </td><td>The short form registration date YYYYMMDD</td></tr> 
				<tr><td>5) userAddr </td><td>DATATYPE_UNT32 </td><td>The user address is the object ID of the user in the repository for the actual user class.</td></tr> 
				<tr><td>6) userType </td><td>DATATYPE_ENUM  </td><td>The actual user class.</td></tr>
			</table>
			<p>A user class is a data class but is declared in the configs by a &lt;user&gt; tag instead of a &lt;class&gt; tag. A user class can be considered to be a subscriber class derivative
because in effect, it automatically inherits the first four subscriber class members. Each user class will have a name that must be unique among all data classes, but that is about
where any similarity between the &lt;user&gt; and the &lt;class&gt; tags end. A user class can add members but may not duplicate any of the subscriber class members. Nor can a user
class be used to initialize a repository. You get a single repository for each defined user class automatically - providing that is, the user class actually has members of its own.
Every user will have an entry in the subscriber repository AND where the user class has members in its own right, an entry in the repository for the user class. In the user's entry
in the subscriber repository the userType will always show the class-id of the user class. If the user class has a repository, the userAddr will show the object-id of the user's
entry in that repository. </p>
			<p>The reason for arranging matters this way is to unify the authentication process and make usernames unique across all classes of user. In websites with only one class of user, this
brings no benefit but where there are multiple user classes, it does. If different classes of user authenticated against different user repositories there would either have to be a
separate login form for each user class OR a lookup for the username in each user class repository every time a new subscriber is added or an existing subscriber tries to log in.</p>
			<p><b>Declaring a Login Facility</b></p>
			<p>Websites can vary considerably in how they facilitate user logins but most of them would probably fit one of the following three general approaches:-</p>
			<table>
				<tr> 
					<td>1) The 'Login Page'.</td> 
					<td>The website has an distinct login page with a specific URL, containing the login form. The form-handler is configured to respond by taking the user to another page depending on the
outcome of the login attempt. Usually if the login is unsuccessful, the login page will simply be re-displayed.</td>
				</tr>
				<tr> 
					<td>2) The Login/Home Page.</td> 
					<td>The website has a page with an 'entry URL' which displays the login form if the user is not logged in but other content if they are. The page is usually implemented by means of the
&lt;xwho&gt; tag. The form-handler in this case would return the user to the entry URL, regardless of the outcome.</td>
				</tr>
				<tr> 
					<td>3) Incuded Login Form.</td> 
					<td>Here the login form does not appear in any one page but in many if not all publically viewable pages by means of an &lt;xinclude&gt; block. This is a very common appraoch in forums
and with mail order websites. Often there is simply a login button which invokes the login form as a JavaScript modal. Howsoever the form is manifest and regardless of outcome, the
visitor is usually returned to the current page.</td>
				</tr>
			</table>
			<p>In addition to the above there can be a separate method for resuming a timed out session, which for expediency may only require the password. The login form for session resumptions
can take any of the above three approaches but it could also take the form of a modal prompt box or similar. Much will depend on how timeouts are catered for within the page itself
as this can vary, particularly between pages that do or do not, contain forms. The recommendation is that any change of state should be readily apparent and a timout is a change of
state. Where a form which may contain sensitive information is being displayed, the timeout notification (which will generally be the password only session resumption form), should
ideally obsure the displayed form. The session resumption form can therefore use approaches (1) and (2) above or be a large modal, but approach (3) is not recomended. Where no form
is being displayed the timeout notification/session resumption form, may use any approach.</p>
			<p>Dissemino login facilities are specified by the &lt;login&gt; tag, which has the following attributes:-</p>
			<table>
				<tr> 
					<td>formURL</td> 
					<td>This is first and foremost the submission URL of the login form, but in approaches (1) and (2) it is also the URL of the page containing the login form. Note that this is the means
by which the approach is selected. If a page with the formURL exists, it will be used for login and so will be required to contain a login form reference. If no such page exists,
appraoch (3) will apply.</td>
				</tr>
				<tr><td>failURL</td> <td>The URL the user will be directed to upon authentication failure</td></tr>
				<tr><td>authURL</td> <td>The URL the user will be directed to upon authentication success</td></tr>
				<tr><td>resumeURL</td> <td>The URL the user will be directed to upon resumption of a lapsed session</td></tr>
				<tr><td>userClass</td> <td>See note below</td></tr>
				<tr> 
					<td>userField</td> 
					<td>If set to 'email', the reqired username will be the email address, if set to 'both' either the username or email address will be accepted. Without thia attribute, the default is to
only accept the username. It is common for websites to use email addresses as usernames as they are inherently unique, users are less likely to forget them and they can be verified
without delay during user registration. There can be downsides however. One half of the login detail is as good as public making it doubly important to have a good password regime.
And people do sometimes change their email address just as they may change other contact details. An email address is not an immutable anchor for an account although it will serve
to uniquely identify a user, regardless of how stable it may be. Developers should note that under Dissemino, users can change their email address at will as long as the change is
verified.</td>
				</tr>
			</table>
			<p>Note that the userClass attribute is for the specific case where the website owners want to have separate login facilities for different classes of user. On recruiting websites for
example, it is quite common to see 'log in as recruiter' and 'login as candidate'. Alternatively there may be a single login facility, but the URL upon authentication success will
vary depending on the user class. This is arranged by having multiple &lt;login&gt; tags, each with a different user class. Where this is done, the presence of a &lt;login&gt; tag
without a userClass attribute, will define the login facility for all other users.</p>
			<p><b>The Logout URL</b></p>
			<p>The Dissemino logout facility is specified by the &lt;logout&gt; tag. A logout request is guarenteed to succeed so it is only necessary to provide the submission URL and the URL of
the page the user will be directed to upon logout. Note that unlike the &lt;logout&gt; tag, the submission URL will NOT be associated with a page!</p>
			<p>The login and Logout facilities can also be declared by the respective C++ functions SetLoginFacilty() and SetLogoutFacility(), whose arguments mirror their respective tags.</p>
			<p>Please note that Dissemino does NOT permit users to have multiple sessions.</p>
1) userName	DATATYPE_STRING	Used to ensure usernames are unique across all user classes.
2) userEmail	DATATYPE_EMADDR	The email address of the subscriber. Can be used as an alternative to username.
3) userPass	DATATYPE_STRING	The user password.
4) regDate	DATATYPE_SDATE	The short form registration date YYYYMMDD
5) userAddr	DATATYPE_UNT32	The user address is the object ID of the user in the repository for the actual user class.
6) userType	DATATYPE_ENUM	The actual user class.
1) The 'Login Page'.	The website has an distinct login page with a specific URL, containing the login form. The form-handler is configured to respond by taking the user to another page depending on the outcome of the login attempt. Usually if the login is unsuccessful, the login page will simply be re-displayed.
2) The Login/Home Page.	The website has a page with an 'entry URL' which displays the login form if the user is not logged in but other content if they are. The page is usually implemented by means of the <xwho> tag. The form-handler in this case would return the user to the entry URL, regardless of the outcome.
3) Incuded Login Form.	Here the login form does not appear in any one page but in many if not all publically viewable pages by means of an <xinclude> block. This is a very common appraoch in forums and with mail order websites. Often there is simply a login button which invokes the login form as a JavaScript modal. Howsoever the form is manifest and regardless of outcome, the visitor is usually returned to the current page.
formURL	This is first and foremost the submission URL of the login form, but in approaches (1) and (2) it is also the URL of the page containing the login form. Note that this is the means by which the approach is selected. If a page with the formURL exists, it will be used for login and so will be required to contain a login form reference. If no such page exists, appraoch (3) will apply.
failURL	The URL the user will be directed to upon authentication failure
authURL	The URL the user will be directed to upon authentication success
resumeURL	The URL the user will be directed to upon resumption of a lapsed session
userClass	See note below
userField	If set to 'email', the reqired username will be the email address, if set to 'both' either the username or email address will be accepted. Without thia attribute, the default is to only accept the username. It is common for websites to use email addresses as usernames as they are inherently unique, users are less likely to forget them and they can be verified without delay during user registration. There can be downsides however. One half of the login detail is as good as public making it doubly important to have a good password regime. And people do sometimes change their email address just as they may change other contact details. An email address is not an immutable anchor for an account although it will serve to uniquely identify a user, regardless of how stable it may be. Developers should note that under Dissemino, users can change their email address at will as long as the change is verified.