/CMD_LOGIN_KEYS No link will be provided to Users quite yet, as this is a powerful tool, and testing needs to be done first. You can access it by manually typing the above URL. Users can create keys to allow login to their control panel. These keys will act like extra password that are valid on their account. However, the key can be set to only be allowed to run certain commands (similar to commands.allow and commands.deny) The keys can also have an expiry date. They can also be set to have a limited number of executions (eg: 1, 2+, or unlimited) Also added an IP list, so only the specific IPs or Ranges listed are allowed to use that key. The main purpose of this feature is for remote API calls to the account, so that they can much more easily restrict it's use, without giving full access, and without giving the main password. It's important to note, that if you restrict the commands using the allow or deny list, basic login functionality using sessions becomes confusing. For example, if you only all CMD_FILE_MANAGER, this does not include "/", so you must access /CMD_FILE_MANAGER right from the point of login (where you use the login form). The path "/" can't be added. HTM files are also not part of the allowed list (but I may add an exception if the demand is there) Upon key creation, a system message will be delivered to that User, to ensure they know it's been created (in case, for whatever reason, someone managed to create it without them knowing) Their current true password is required for key creation and modification. The api version: CMD_API_LOGIN_KEYS is fully implemented (see the below for forms for details) The "Key Name" values are only for your own tracking benefits. They're not used in any fields when logging in. You use your normal DA username, along with the key for the password. Entire feature can be turned on/off with the directadmin.conf option: login_keys=1 where 1 is the internal default (enabled by default) Note that suspending a User will also suspend the login keys (adds the ! character in front of the crypt) =========================== CMD_API_LOGIN_KEYS --------------------------------- CREATING A KEY method: POST keyname=nameofthekey #this just for your own reference, and not the login username, The normal User's username is still used at login time. a-zA-Z0-9 key=secret #the new secret password. Usually something long, say 128 chars. key2=secret #re-poost key never_expires=yes|no #yes=key lasts forever. If set to no, then ensure you set the expiry values. expiry_timestamp=1568749148 #timestamp as to when it will expire, only used if never_expires=no. Note, you can alternatively pass the hour,minute,month,day,year values as per html form. max_uses=0 #if set to >0 then this is the counter for the number of calls this key is allowed to make. clear_key=no #if set to yes, once max_uses is hit, or exipry is hit, the key is automatically deleted. allow_html=no #if set to yes, the key can be used to acecss HTM_ CSS, and image files, etc.. basically things needed for browser/GUI acess, like a session login. Script based CMD_API calls don't need this. passwd=currentpass #password of the current account. If using the login-as method, then it's the password used for the login-as (eg: admin's password) OPTIONAL VALUES when creating a key select_allow0=CMD_... select_allow1=CMD_... select_deny0=CMD_... select_deny1=CMD_... ... etc.. These select_* values are optional. Select the commands you wish to allow or deny for this key. ANY values in the command.allow imply all other unlisted commands are denied. The ALL_ADMIN, ALL_RESELLER, ALL_USER commands can be used instead of listing all of those commands. These ALL_* values are useful in the even new commands are added into DA, they'll automatically be listed, and also allow you to allow/exclude things in creative ways. Anything in the allow list will override the deny list, if that combination is needed. For most cases, just listing the commands you want to allow or deny are what most people go with. It's often a good idea to disble CMD_LOGIN_KEYS and CMD_API_LOGIN_KEYS in a given key, to avoid the creation or removal of other keys. RESTRICT new key to certain IPs You can (and should when possible) restrict a key to the IP that will be connecting to DA. This prevent anyone else from using the key in the event the key value (password) is stolen/lost. The format is one IP per line (newline character between) ips=22.214.171.124\n126.96.36.199-9\n::1\na:b:c:d::0\n1:2:3:4:5:6:7:8-g --------------------------------- MODIFYING A KEY The values passed are exactly the same as key creation, except: keyname= #must match the value you are editing action=modify #must pass this to use modify-mode. key|key2= #can be left blank if you don't wish to alter the values. Everything else must still be passed as if it were a fresh copy. This implies that you do need to pull all currently values before you can push them back again, since all items need to be known (cannot just edit one part and exclude other info) --------------------------------- VIEWING A KEY: A 1.59.0+: method: GET action=show_modify keyname=keyname #name of the key to view Returns URL encoded list of values. You can alternatively work with json output, by adding this GET value: json=yes The json=yes value works with CMD_LOGIN_KEYS prior to 1.59.0. =========================== Feb 8th, 2012 - 1.40.3 ** BUG Found ** If you're using the httpd-auth login method (as most APIs do), there is a limit of 40 characters for the keys. If you key value is more than 40 characters (the random button creates 64 character values), then the login will fail. There are fixed binarie in the pre-release section which support the full 64 character length. Session based logins with the keys are not affected by this bug.