home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hall of Fame
/
HallofFameCDROM.cdr
/
rbbs
/
rbbsdocs.lzh
/
RBBSDOCS.8
< prev
next >
Wrap
Text File
|
1990-11-05
|
9KB
|
155 lines
UNIQUELY IDENTIFYING YOUR CALLERS 8-1
8. UNIQUELY IDENTIFYING YOUR CALLERS
------------------------------------
All callers need a way to identify themselves to RBBS-PC and to other
callers. RBBS-PC expects each caller to set a password so that other
callers cannot easily pretend to be that caller. Callers are most easily
known on bulletin boards the same way they are known in real life - by
first and last name. This is why the default configuration in RBBS-PC uses
first and last name to IDENTIFY users. The first/last name is the caller's
identity or ID.
RBBS-PC also allows the SysOp to identify callers uniquely by something
other than their first and last names. Perhaps the SysOp wants a one word
alias to be allowed, or perhaps callers must use a preassigned access code
(access code, employee number, account number, etc.). RBBS-PC allows ANY
FIELD inside the users file to be used for identification. Since there are
empty, unused areas in the user file, a SysOp can even create a new field
to be used for caller identification.
When anything other than name is used to identify users, RBBS-PC still
wants callers to specify their names. It just does not use that
information to identify them.
A fairly common problem on bulletin board systems with large user lists is
that two callers can have the same first and last name. A caller discovers
this when they are unexpectedly asked for a password on the first call to a
new system, indicating that another caller has already used that name.
Further, since RBBS-PC is used world-wide many non-English speaking
countries have callers with names that have embedded blanks, etc. RBBS-PC
alleviates this problem by allowing interior blanks in first and last
names. Thus JIM JONES can register as JIM K JONES or JIM JONES SR or JIM
JONES III.
By allowing ANY field inside the user record to be used to uniquely
identify individual callers, RBBS-PC alleviates the basic problem of having
two callers with the same name.
This additional INDIVIDUATION field is used to distinguish callers with the
same ID. When individuation is used, callers will have to specify both the
identifying and individuation field. Both are used to find a record in the
users file. This individuation field can likewise be a new field created
by the SysOp. For example, the SysOp can specify that callers be uniquely
identified by both their name and their CITY/STATE. Alternatively the
SysOp can specify that callers are to be uniquely identified by their
telephone number, which would be a new field for RBBS-PC to store. Note
that when using individuation, ALL callers must use it, not just the ones
with identical names.
8.1 Setting Up Identifying and Individuation Fields
---------------------------------------------------
The identifying and individuation fields in RBBS-PC are controlled by
parameter 41 through 46 in CONFIG. The default is to use the caller's
first and last name to uniquely identify a user.
The fields available to uniquely identify a caller (other than the caller's
first and last name) are designated in CONFIG by the starting position in
the users file and length. It is essential therefore to understand WHERE
FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for a detailed
layout of the user file.
RBBS-PC 17.3A TECHNICAL REFERENCE MANUAL 8-2
RBBS-PC's flexibility requires care when selecting the locations of fields
used to identify and individuate, because options can be selected that make
no sense. For example, it is possible to specify the user preference
field, which means that every time a user changed preferences, such as
default protocol, the user would have a different ID.
There are only two fields in the user file that make sense for identifying
users:
1) first/last name (column positions 1-31), or
2) a field designated by you as the SysOp for your RBBS-PC. For a
SysOp-designated field, only 4 choices make sense:
a) none,
b) name (columns 1-31),
c) city/state (columns 63-86), or
d) positions 87-97 in the user record currently "unused."
Positions 87-97 of the users record (currently unused) provides a potential
11 columns to use for SysOp designated fields. However, there is no
guarantee that these positions will not be used in future releases of
RBBS-PC. Additional fields will be used from the far right. Any SysOp
intending to utilize this area of the users record is safest if the field
selected begins in column 87 and is as short as possible.
When a SysOp-designated field is created, the SysOp must also supply the
prompt to be used with the field. The prompt is what is displayed to the
caller when asking for the value of the field.
RBBS-PC uses the callers first and last name for the "to" and "from" fields
for messages even when the users name is not the field used to uniquely
identify callers.
8.2 Preloading Identities For Instant Access
--------------------------------------------
SysOps who operate bulletin boards that are open to new callers have no
problems giving a new caller instant access -- new callers register, set
their identity and password, and are recorded in the USER file.
SysOps that operate bulletin boards that are only available by
subscription or who delay access operate differently -- a user must
already know and be able to state identity, individuation, and password in
order to get on. To add a new user, the values of these fields must be
communicated back to the caller in order for them to have access. To
overcome this cumbersome approach, some SysOps allow new callers on their
system (at a reduced security level) and then raise the security level of
the caller once the caller has met whatever criteria the SysOp has set for
access to the system.
Typically new callers must call back and continue to check to see if their
security level has been raised. Systems that do not let new callers on
require the SysOp to enter the appropriate information for each new user,
contact the new caller by mail or phone, and let them know how to connect
to the RBBS-PC. Both approaches introduce delays to new callers for
getting on and additional time, expense and overhead for the SysOp.
RBBS-PC provides a systematic solution to the problem of delayed access for
new user. A SysOp can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD
OR PASSWORD. These fields can be left blank. When a caller logs on with a
proper ID and RBBS-PC finds an individuation value or password that is
UNIQUELY IDENTIFYING YOUR CALLERS 8-3
blank, it lets the caller set the value of those fields without requiring a
match. Subsequent calls, but not the first, must match the value set for
individuation and password.
Even though a SysOp can add a user and leave the password and individuation
blank, this still requires that the SysOp add the user only after an ID is
agreed to by both parties. What if this access is still not fast enough?
The solution provided by RBBS-PC is for the SysOp to "pre-load" IDs and
give out a pre-loaded ID to the caller for instant access, so that the
client does not have to wait even for the SysOp to add the ID. Since there
is no way to set in advance how a user wants to be identified, the SysOp
can set up essentially random account IDs which are difficult to guess.
Callers who pre-pay the subscription fees can be given a valid pre-loaded
ID for instant access. The ability of RBBS-PC to use any field for an ID,
and let the first call set individuation and password, means that RBBS-PC
can support boards where instant access is a critical part of their
service.