Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
access:requirements [2011/11/12 02:18] – digitalmanaccess:requirements [2018/10/25 14:36] – New ARS keywords: PETSCII, COLS, ROWS, TERM digital man
Line 1: Line 1:
 ====== Access Requirements ====== ====== Access Requirements ======
  
-ARS stands for Access Requirement Strings. Access requirement strings are used +Access Requirement Strings (ARS) are used to specify the requirements of a specific Synchronet user account in order to have access to specific areas or functions of a Synchronet BBS. 
-to specify the requirements of a user to have access to features/sections of a + 
-Synchronet BBS. The string can consist entirely of English keywords and+===== Overview ===== 
 + 
 +You will find in [[util:SCFG]] and other Synchronet [[:config:|configuration]] files, places where the sysop may specify requirements to access a specific area or feature of the BBS. Usually these items will have ARS (Access Requirement String) or just "Requirements" as part of the name. 
 + 
 +Most ''Access Requirements'' are "default allow", meaning, if there are no requirements specified (i.e. the requirement string is blank), then the default behavior is **allow** access to that specific area/function to //any// user. 
 + 
 +Some ''Requirement'' strings are "default deny", meaning, if there are no requirements specified (i.e. the requirement string is blank), then no user will match that requirement. Examples of "default deny" requirements: 
 + 
 +  * Operator Requirements 
 +  * Exemption Requirements 
 +  * Moderated Posting User 
 +  * Pre-pack QWK Requirements 
 + 
 +===== Configuration ===== 
 + 
 +[[util:SCFG]] has an interactive ''Requirements'' dialog screen which allows easy addition or clearing of the most common requirement parameters. 
 + 
 +<code> 
 +╔══════════════════════════════════════════════════════════╗ 
 +║                  Main Group Requirements                 ║ 
 +╠══════════════════════════════════════════════════════════╣ 
 +║ │Requirement String ()                                   ║ 
 +║ │Clear Requirements                                      ║ 
 +║ │Set Required Level                                      ║ 
 +║ │Set Required Flag                                       ║ 
 +║ │Set Required Age                                        ║ 
 +║ │Set Required Sex                                        ║ 
 +║ │Set Required Connect Rate                               ║ 
 +║ │Set Required Post/Call Ratio (percentage)               ║ 
 +║ │Set Required Number of Credits                          ║ 
 +║ │Set Required Upload/Download Byte Ratio (percentage)    ║ 
 +║ │Set Required Upload/Download File Ratio (percentage)    ║ 
 +║ │Set Required Time of Day                                ║ 
 +║ │Set Required Day of Week                                ║ 
 +║ │Set Required Node Number                                ║ 
 +║ │Set Required User Number                                ║ 
 +║ │Set Required Time Remaining                             ║ 
 +║ │Set Required Days Till Expiration                       ║ 
 +╚══════════════════════════════════════════════════════════╝ 
 +</code> 
 + 
 +From this dialog screen, you can edit the Requirement String directly, or use the additional menu options to add the most common requirement parameters (and values) or clear the requirement string. 
 + 
 +===== Syntax ===== 
 + 
 +Access Requirement Strings can consist entirely of English keywords and
 numbers or use short-hand symbols to fit a large number of security numbers or use short-hand symbols to fit a large number of security
 requirements into the limited space allowed for access requirement requirements into the limited space allowed for access requirement
Line 11: Line 56:
  
 <code> <code>
-usage: [not] [parm] [not] [equal] <value> [or] [and] [...]+usage: [not] [param] [not] [equal] <value> [or] [and] [...]
  
 where: not      is the word "NOT" or the symbol '!' to specify reverse logic where: not      is the word "NOT" or the symbol '!' to specify reverse logic
-       parm     is one of any keywords (or short-hand symbols) that specifies+       param    is one of any keywords (or short-hand symbols) that specifies
                 a specific required parameter (default is LEVEL)                 a specific required parameter (default is LEVEL)
        equal    is the word "EQUAL", "EQUALS", the words "EQUAL TO", or the        equal    is the word "EQUAL", "EQUALS", the words "EQUAL TO", or the
Line 26: Line 71:
 </code> </code>
  
-===== Logic Operators =====+==== Logic Operators ====
 Logic operators may exist between one or more Boolean or Value Parameters. When no logic operator is specified, the default logic requirement is GREATER_OR_EQUAL and when multiple parameters are specified, ''AND'' (i.e. all the specified parameters must be evaluated to a //TRUE// condition). Logic operators may exist between one or more Boolean or Value Parameters. When no logic operator is specified, the default logic requirement is GREATER_OR_EQUAL and when multiple parameters are specified, ''AND'' (i.e. all the specified parameters must be evaluated to a //TRUE// condition).
  
Line 33: Line 78:
 |NOT       |  ! |Logical negation (e.g. NOT EQUAL) | |NOT       |  ! |Logical negation (e.g. NOT EQUAL) |
 |EQUAL       |  = |Equality required | |EQUAL       |  = |Equality required |
-|OR       |  FIXME  |Either of two or more parameters is required |+|OR       |  %%|%%  |Either of two or more parameters is required |
 |             |  (       |Begin nested requirement| |             |  (       |Begin nested requirement|
 |             |  )       |End nested requirement| |             |  )       |End nested requirement|
  
-===== Boolean Parameters =====+==== Boolean Parameters ====
  
 Boolean parameters are evaluated as //true// or //false// without any specified value for comparison. Boolean parameters are evaluated as //true// or //false// without any specified value for comparison.
Line 43: Line 88:
 ^Keyword      ^Symbol ^Description  ^ ^Keyword      ^Symbol ^Description  ^
 |ACTIVE       |         | User has an active account (not marked DELETED or INACTIVE) | |ACTIVE       |         | User has an active account (not marked DELETED or INACTIVE) |
-|ANSI       |  $[ | User has ANSI terminal |+|ANSI       |  $[ | User is using an ANSI terminal | 
 +|PETSCII      |         | User is using a PETSCII terminal |
 |DELETED      |         | User account is marked DELETED | |DELETED      |         | User account is marked DELETED |
 |DOS       |         | BBS is running on MS-DOS | |DOS       |         | BBS is running on MS-DOS |
Line 60: Line 106:
 |UNIX       |         | BBS is running on a UNIX clone | |UNIX       |         | BBS is running on a UNIX clone |
  
-===== Value Parameters =====+==== Value Parameters ====
  
 Value parameters require a //value// (e.g. word or number) following the parameter keyword or symbol. This parameter is compared against the criteria of the system or the user using the current comparison logic. Value parameters require a //value// (e.g. word or number) following the parameter keyword or symbol. This parameter is compared against the criteria of the system or the user using the current comparison logic.
Line 66: Line 112:
 ^Keyword      ^Symbol ^Description  ^ ^Keyword      ^Symbol ^Description  ^
 |AGE |$A |User's age (years since birthdate, 0-255)| |AGE |$A |User's age (years since birthdate, 0-255)|
-|BPS |$B |User's current connect rate (bps)|+|BPS |$B |User's current connect rate (bits-per-second; Telnet, RLogin, and SSH connections will have a BPS value of 30000)| 
 +|COLS           |       |Terminal columns (e.g. 40 or 80+) |
 |CREDIT |$C |User's number of credits in Kilobytes (0-65535)| |CREDIT |$C |User's number of credits in Kilobytes (0-65535)|
 |DAY |$W |Day of the week (Sun, Mon, Tue, etc. or 0-6)| |DAY |$W |Day of the week (Sun, Mon, Tue, etc. or 0-6)|
Line 91: Line 138:
 |RANDOM |$Q |Random number between 0 and value argument (0-65535)| |RANDOM |$Q |Random number between 0 and value argument (0-65535)|
 |REST |$Z |[[Restrictions]] flag (A-Z)| |REST |$Z |[[Restrictions]] flag (A-Z)|
 +|ROWS           |       |Terminal rows (e.g. 24)|
 |SEX |$S |User's sex/gender (M or F)| |SEX |$S |User's sex/gender (M or F)|
 |SHELL          |       |User's selected command shell internal code| |SHELL          |       |User's selected command shell internal code|
 |SUB |$H |Current message sub-board (Internal code or 1-65535)| |SUB |$H |Current message sub-board (Internal code or 1-65535)|
 +|TERM           |       |Terminal type (string)|
 |TIME |$T |Time of day (HH:MM, 0-23:59)| |TIME |$T |Time of day (HH:MM, 0-23:59)|
 |TLEFT |$R |User's time left online (minutes, 0-255)| |TLEFT |$R |User's time left online (minutes, 0-255)|
Line 104: Line 153:
 |USER |$U |User's number (1-xxxx)| |USER |$U |User's number (1-xxxx)|
  
-===== Examples =====+==== Examples ====
  
 FIXME - need to import from [[http://synchro.net/docs/security.html]] FIXME - need to import from [[http://synchro.net/docs/security.html]]

Trace: