Table of Contents
This section details commands which have been added and commands which have been changed from RFC1459. Responses from the server are discussed in greater detail in later sections.
Create an "access entry" for an object to grant or deny access to an object, including a channel, a user, or the server. ACCESS LIST is used to list all access entries for an object and CLEAR is used to clear all entries or all entries of the same level.
Syntax 1:
ACCESS <object> LIST
Syntax 2:
ACCESS <object> ADD|DELETE <level> <mask> [<timeout> [:<reason>]]
Syntax 3:
ACCESS <object> CLEAR [<level>]
<object> The object to which access is being granted or limited. Can be a channel name, nickname, $ or *.
<level> The level of access being given or taken away. Can be:
Table 3.1. Access Levels
Level | Description |
---|---|
DENY | Disallow access to an object that is accessible |
GRANT | Allow access to an object that is inaccessible |
HOST | Channel host access to specified channel |
OWNER | Channel owner access to specified channel |
VOICE | Voice access to specified channel |
<mask> Mask to identify user by nickname, userid, host or server characteristics. Supports wildcards * and ?.
<timeout> Minutes until the access entry is removed. A value of 0 indicates unlimited duration.
<reason> Text reason shown when users are denied access due to the access entry.
In this specification possible error messages are listed.
IRCERR_BADLEVEL
IRCERR_DUPACCESS
IRCERR_MISACCESS
IRCERR_TOOMANYACCESSES
IRCERR_TOOMANYARGUMENTS
IRCERR_BADCOMMAND
IRCERR_NOTSUPPORTED
IRCERR_NOACCESS
Editor's Note | |
---|---|
In this particular specification of IRCX, there was no error message specifically for telling a user that some entries couldn't be removed because they didn't have the proper authority to remove them. Current implementations use an error message from a previous version of the IRCX draft. The error message is defined as follows: 922 - IRCERR_ACCESSSECURITY: Some entires not cleared due to security The addition of this error message is entirely optional, however it is highly recommended this error message is used, to let the client know that some of the access entries they attempted to clear were not removed because they lacked the privileges to do so (see "Remarks" for more information). |
An object with GRANT access entries but no DENY entries is assumed to be off-limits to those users not covered by the GRANT entries. If there are multiple entries in the access list, the list is processed in the following order: OWNER, HOST, VOICE, GRANT, DENY.
Hosts and Owners may add and delete access entries for their channel. Hosts may not remove access entries added by owners. Any user may add and delete access entries for themselves. Sysops and sysop managers on a server may add and delete access entries for that server or the entire network.
A user who has blocked another user does not get any messages from the blocked user, including invites.
Example 3.1. Make a user, "piper", a channel host when they join the channel, "#mychan"
ACCESS #mychan ADD HOST piper
Example 3.2. Grant normal access to the network to a few people but deny access to all others
ACCESS * ADD DENY * :closed for private party
Example 3.3. Delete the DENY access record on the network that denies access to '*'
ACCESS * DELETE DENY *Note | |
---|---|
(this doesn't delete other DENY access records such as '*.com') |