Signup processes gate user acquisition of login privileges. New companies or users can only acquire login privileges by successful completion of controlled processes such as membership application and company representative signup. Some organizations accept new member applications through online forms while other organizations use an invitation-only process. Once a company has been granted membership, users who belong to that company will be allowed to signup as representatives. There are several ways control can be interjected into these processes, including restrictions imposed through Web forms, billing and moderator approval.

Online membership applications may include click-through forms used to indicate agreement with terms and conditions. A moderation step provides opportunities for hardcopy prerequisites such as signed IPR agreements to be delivered and subjected to a legal review and approval before membership is granted.

Prospective member company representatives may be required to provide a company-issued email address as their primary email address by enforcing accepted domains, and may be matched with their company based on this address. To give the company control over who represents it to the organization, the company's Primary Contact or Company Admin may be allowed to add new representatives directly.

Individuals who belong to staff companies or work directly for the organization aren't allowed to signup online, since these companies may be assigned types that confer privileged roles from the Admin and Editor categories. Instead, administrators and staff must be manually added by other administrators.

As a company or user is added to the Kavi Members database, they are assigned one or more types to classify them according to their relationship to the organization. These types confer whatever roles are needed to grant the level of site access required by that type.

Roles that confer access to the Members level may be conferred through types assigned through membership or through types assigned to staff or administrators, rather than members and member company representatives.

When a member company representative is signed up as a Primary Contact, Company Administrator or Company Editor, they are automatically assigned a corresponding type that confers the administrative or editorial role with the permissions they need to manage company data or edit company-maintained content on the site.

Types designed for organization staff and administrators are manually assigned by other administrators who already hold the same (or higher) level of privileges.

Even if a company or user exists in the database and has been assigned a type that confers roles, they won't be able to access the site unless their status is 'active'. When set to 'inactive', the Status setting overrides and disables login privileges granted through roles.

For example, a new user is added to the Kavi Members database as soon as their membership application is approved, even though the membership term hasn't started. User Types assigned through membership are added automatically at the same time. But this user shouldn't appear in Members rosters or be able to login to the site to exercise membership privileges until the membership becomes current. Since this membership is in a pending state when the individual is added, their status is set to 'inactive'. When the membership goes current, this individual's status will be automatically reset to 'active'.

Administrators can reset Status manually to toggle user access and visibility (whether the user appears in rosters, etc.) off and on, although setting a user to 'active' won't restore access if the user's types and roles have been revoked. This feature can be used to temporarily revoke access for a company or user who has temporarily lost their standing in the organization because of lapsed membership, uncertainty about whether a user is still at the member company they signed up to represent, etc.

Once a user is added to the Kavi Members database, assigned types that grant roles and access and activated, an email with a login link is sent to the user's primary email address. The user clicks this link to access protected areas of the organization's Web site for the first time, and is taken directly to a page where they can set the password they will use to access the site from now on.

Kavi Members manages login for Kavi-supported Web sites. Like all Kavi applications, it follows industry-standard best practices for Web site security, as published in the Kavi Development Standards and Guidelines. Sites that have Kavi® Billing and Kavi® Commerce installed have the added protection of SSL encryption for pages that manage billing information. Users must login and be authenticated (the username and password they provide must match a username and password in the database) before they can access any of the protected areas of the site. Every authenticated user has access to the My Account page where the user can manage their personal data. But whenever the Web server receives a request to display a new page from a user's browser, it verifies whether the user's role cache contains a role that grants access to the page and its content.

A Web page is the basic unit of a Web site, but page-level controls can be exerted over elements contained within a page, including sub-forms and links. Access to a page and its child elements is controlled through roles. When a user tries to view a Web page, their browser sends a request to the Web server which checks the user's role cache to see what roles the user has. Then the server checks the page to see what roles are allowed to view it. If the user has one of these roles, the page is displayed. Subelements within the page may require other roles, so any content that requires a role the user doesn't have in their role cache will remain hidden.

Here is an example of how the Members Landing page might display differently depending on a user's role cache. The first view shows the way the page is displayed to a user who has been assigned the Organization Admin type that conveys the 'org_admin' role. The second view shows the way the same page is displayed to a user who has been designated as Primary Contact for a Board Member company and has been assigned types that convey the 'member', 'board' and 'company_admin' roles.

Figure 11.2. The Members Landing page as displayed to an Organization Admin or other user with the 'org_admin' role.

The way the Members Landing page might display to someone with the 'org_admin' role. This role is assigned to highly privileged users in charge of maintaining the organization's Web site. It provides access to the Admin Area and lower Member and Public levels. This is especially evident in the left hand navigation pane, which includes links to Admin Home and Reports Home that aren't present in the page view displayed to the Primary Contact in the next example.

Figure 11.3. The Members Landing page as displayed to a Board Company Primary Contact or other user with the 'member', 'board' and 'company_admin' roles.

The way the Members Landing page might display to someone with the 'member', 'board' and 'company_admin' roles. The left hand navigation pane includes links to Public and Members Areas that are displayed to all members, with an additional Board-Member-only link that is only displayed to board members. It also displays the 'My Company' link, which is only displayed to Primary Contacts or other users who have the 'company_admin' role. Tools available through this link allow Primary Contacts to manage their company's roster and other data. This link isn't displayed in the first example, because the user with the 'org_admin' role has access to tools that manage the data for all companies, rather than one specific company.