Please note that the .HTACCESS method of access control (that uses
.HTACCESS files located in directories) is not supported by sreLite.
IVa. The USERS.IN file
The syntax of entries in USERS.IN is:
USERNAME PASSWORD client_Privilege_list
where all fields can contain letters (A-Z, a-z), numbers (0-9), and _ characters:
> Username is a case insensitive username
The format of username is one of:
username -- username applies to all hosts, including the "Generic" host"
host_nickname/username -- username ONLY applies to requests to host_nickname
/username -- username ONLY applies to requested to the generic host
> Password is possibly case-sensitive (depending on the client's authorization protocol)
It can contain A-Z, a-z, _, and 0-10.
> Client_privilege_list is an optional space delimited list of "privileges".
You can also use a * for either username or password ---
>> the * character for password means "any password will do".
>> the * in USERNAME is a wildcard -- it means "any username
(say, for this host_nickname)
IVa.1. Host specifc, generic host, and global usernames.
When sreLite2 compares entries in USERS.IN to the username supplied by the client,
it will look for 4 different names:
- The "host-specific" username. This could be the "generic" host, signified by
username.
- The non-host-specific username.
- The host-specific wildcard
- The default wildcard
Thus, if the host nickname is TIGER and the username is JONES
then the following entries will be looked for in the userfile
TIGER/JONES
JONES
TIGER/ *
*
Or, for a request to the "generic host" (i.e.; if you did NOT specify any
host nicknames), and the username is PAUL:
/PAUL
PAUL
/ *
*
Note that /PAUL means:
| check for username PAUL on
a request to the generic host only
|
whereas PAUL means:
| check for username PAUL on ALL requests
(perhaps after checking for a host-specific PAUL).
|
In any case, if a username is found, it's password is compared to what the
client provided. If the password does not match, then the username is not
a match.
IVa.2 Example of a USERS.IN file:
; this is a comment (starts with ;)
OUTATOWN SHEP2 INHOUSE
MASTER1 12ISIE6 SUPERUSER
user1 1user Priv1 Priv2
ANONYMOUS * PUBLIC
TIGERS/Jill cats dogs
SHOP/* shopper visitorx
/BILL PILL SILL
TIGERS/BILL WILL NILL
BILL HILL MILL
V. Special Directives
Special directives are selectors that begin with a !.
Currently, two special directives are supported:
!RESET
|
Reset sreLite2 parameters. This requires SUPERUSER
privileges
|
!RANGE:rtype=a1-a2/asel |
Add a RANGE item to the
IM information. If you've selected
XRANGE as your
IM_DEFAULT,
this RANGE IM
information will be used to extract a portion of aselector.
Rtype defines how to extract this range:
- If rtype= BYTES, a1 and a2 should be integers.
- If rtype= STRINGS, a1 and a2 should be url-encoded, case
sensitive, strings. Be sure to use + for spaces!
Note that asel should be a normal selector,
which will be subject to the usual access
controls and alias transformations.
For more information on XRANGE, see IM_USE.HTM.
|
VI. Definitions
The following sundry definitions and descriptions of sreLite2
concepts are listed in rough alphabetical order.
- CGI-BIN
- CGI (Common Gateway Interfact) - BIN is a standard by which server side
("gateway") programs can be invoked. It uses environment variables to pass
data, as well as standard input and output.
- Client
- The Client (sometimes referred to as the requester) is the individual
requesting a URL -- where the URL may point to a file, or may invoke a script.
Typically, the request was generated by someone running a
Web Browser, and clicking on a link or submitting a FORM.
- Default Data Directory
- The Default Data Directory is the root directory of
your web site -- it
(and it's subdirectories) are the usual locations for your HTML documents,
images, etc. By default, the SRE2002 Data Directory is used as the
Default Data Directory.
A simple example might help:
- Request selector
- When a client sends a request to a server, it contains three components:
the method, the selector, and the protocol. For example, in the following
request line: GET /FOO1/BAR.HTM HTTP/1.0
- the http method is: GET
- the selector is: /FOO1/BAR.HTM:
- the http protocol is: HTTP/1.0:
Note that if a GET HTTP method was used, the request selector may contain
information following a ?
For example... /SHOWINFO?DATABASE=PRICES&ITEM=APPLES
- Selector-specific
- Selector-specific means a piece of information specific to a request
selector. In other words, this means that sreLite will use the value of
the request selector to find information (such as the required privileges).
- URL: Uniform Resource Identifier (URI), and Uniform Resource Locator (URL)
- URIs (which are basically synonymous with URLS) are a scheme
for specifying Internet resources using a single line of
printable ASCII characters. A URL should contain a protocol, domain name,
port number (optional), the location of the resource, and an (optional)
option list (following a ?).
Example: http://WWW.SREHTTP.ORG:80/calc/calc.htm
- Wildcard matching
- Wildcard matching use the * as a wildcard character in a natural fashion.
Examples:
/JOE/* will match /JOE/FOO.HTM
/JOAN/SRCH.HTM?* will match /JOAN/SRCH.HTM?search+me
/JOAN/SRCH.HTM?* will NOT match /JOAN/SRCH.HTM
(/JOAN/SRCH.HTM* will match BOTH these examples)
/PETS/*INDEX.HTM will match
/PETS/INDEX.HTM, /PETS/CAT/INDEX.HTM and /PETS/PUPPY/LAB/INDEX.HTM
but will NOT match
/PETS/CAT/PUREBRED.HTM
Wildcard matching is used when examining SEL_REQUIRES, ALIASES, and
INHOUSEIPS.
- Wildcard matching with substitution
- Wildcard matching with substitution is similar to wildcard matching.
However, rather then being a "many to one" match, it is a "many to many"
match.
The basic rule is that both a "target" and a "replacement" should contain *
characters. When a wildcard match between the target and a candidate occurs,
the "covered portion of the candidate" is inserted into the "replacement".
In other words, the * character in the replacement is deleted, and the
"covered portion" is inserted.
Example:
VII. Some procedures in the SRELITE2 procedure library
The following lists a few useful procedures provided in the sreLite2
procedure library. These complement the procedures in the SRE2002
procedure library (as described in SRE2PRC.HTM).
SREL2_RESET Reread configuration files
SREL2_MULT_SEND Send a multi-part document
SREL2_GET_USERINFO Extract information on a user
SREL2_CHECK_PRIVS Check a list or privileges against a second list
--------------------------
SREL2_CHECK_PRIVS
Check to see if the user has one of the required privileges.
Syntax:
imatch=srel2_check_privs(privs_to_check,privs_granted)
where:
privs_to_check : a space delimited list of privileges (as may be specified
if a sel_requires entry).
privs_granted: the privileges of this user; say, as derived from srel2_get_userinfo
(that is, as specified in USERS.IN).
and
imatch:
0 -- none of the the names in the userlist have any of the
privileges contained in the privs_to_check list
n -- the first privilege, in the privs_to_check list, found in privs_granted
Notes:
* If privs_granted='', then always return 0
* If privs_to_check='', then always return 0
* a "*" in Privs_to_check matches anything (thus, if * is the 3 element in
privs_to_check, then always return 1, 2, or 3).
SREL2_GET_USERINFO
Determine username, password, and privileges; given either a list
of possible usernames, or (more commonly) based on information found
in an authorization request header
Syntax:
imatch=srel2_get_userinfo(userlist,authh,host_nick,id_info)
where:
userlist: Optional.
The list of users to try finding privileges for.
The first "existing" user in this list is used
If blank, then construct a user list (see below)
If userlist is not specified (which is the usual mode of operation),
then the following two variables may be used:
authh: optional. The authorization header. If not provided, it will
be looked up
host_nick: optional. The host nickname.
If not provided, it will be looked up.
If there is no host nickname for this request, the "generic"
host is assumed.
id_info: optional, The id_info (include this to speed up processing a bit)
and
Imatch:
' ' -- No match. This can happen for a number of reasons:
1) none of the the names in the userlist could be found in the
userfile
Note that if userlist IS specified, then passwords are NOT checked
2) userlist was not specified, and
a) there was no authorization request header
b) the username in the authorization request header was not
found in the userlist, or had a mismatching password
user_record -- Match found. The user_record contains:
username password priv1 ... privn
Note that the username indicates which username (in the
possibly auto-generated userlist) was matched.
Notes:
* When userlist is not specified, a userlist containing 4 usernames is constructed.
These are derived from the authorization header; and are subject to "password" checking.
The 4 names consist of:
1) The "host-specific" username.
For request that are not to host for which a host-nickname exist (that is, for
requests to the "generic" host), use /username (i.e.; preface the username
with a /).
2) The non-host-specific username.
3) The host-specific wildcard
4) The default wildcard
Thus, if the host nickname is TIGER and the username is JONES
then the following entries will be looked for in the userfile
TIGER/JONES
JONES
TIGER/*
*
Or, for a request to the "generic host" (i.e.; if you did NOT specify any
host nicknames), and the username is PAUL:
/PAUL
PAUL
/*
*
In any case, if a username is found, it's password is compared to what the
client provided. If the password does not match, then the username is NOT
used (a ' ' is returned).
* A return of ' ' often means you should send an authorization response
(i.e.; using sre_auth_response)
SREL2_MULT_SEND:
Send a piece or a part of a response.
For the details, see MULTSEND.DOC.
SREL2_RESET:
Reset the sreLite2 configuration parameters -- re-read sreLite2.CFG,
USERS.IN, or HOSTINFO.CFG.
Syntax:
astat=srel2_reset(not_params,douser,dohost)
where all the parameters are optional:
doparams = if not_params<>1, then reread sreLite2 configuration
parameters file (sreLite2.CFG)
douse = douser=1, then reread the username file (USERS.IN)
dohost = if dohost=1, then reread the SRE2002 host definitions file
(HOSTINFO.CFG)
astat = if no errors, a 1 is returned
Otherwise, 'ERROR an_error_message'
Example:
f=srel2_reset() -- just reread sreLite2 configuration parameters
f=srel2_reset(,1) -- configuration parameters and user
f=srel2_reset(1,,1) -- reset hostinfo, do NOT reset configuration
VII. Basic copyright and it's never our fault disclaimer:
Copyright 2002 by Daniel Hellerstein.
As an component of the SRE2002 suite, the disclaimer for SRElite2 is the same.
Basically,
Permission to use this program for any purpose is hereby granted
without fee, provided that the author's name not be used in
advertising or publicity pertaining to distribution of the software
without specific written prior permision.
SRELITE2 and related product are NOT guaranteed to be secure.
THIS SOFTWARE PACKAGE IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED
WARRANTY.
For the complete disclaimer, please see SRE2002.HTM.