MultiUser

Since the version 2.03, MLdonkey features a MultiUser system.

MLdonkey previously used separate passwording systems from each interface; It is now using a common database of login/password pairs to authenticate users connecting from all interfaces (telnet, http, gui).

User authentification could be used to restrict the access to informations and commands available to each user, but that's not implemented (yet).

Contents 1 (Re)Define passwords 2 Authentification 3 List of multi-user related commands 4 Temporary solution for restriction of access to a administration, if you have MLDonkey and webserver installed on same machine: 5 Comments on a new multi-user system 6 To-Do

(Re)Define passwords

At the beginning, only the special user admin, with an empty password, is defined. The admin can add users, or modify previous passwords, using

useradd <user> <password>

example: useradd admin secret to modify the admin password

non_admin users can change his own password with passwd command

You can also remove users with userdel.

Authentification

The syntax of the auth command, used to authenticate telnet connections, is now

auth [user] [password]

The GUI has been enhanced so you can specify a login in addition to the password. The web interface already required a login/password combo.

Remark: user "admin" is implicit in telnet and gui interfaces if only password is specified.

List of multi-user related commands

chgrp 

change group of download

chown 

change owner of download

dgroup 

print default group of logged-in user

groupadd 

add new mldonkey group

groupadmin 

change group admin status

groupdel 

remove an unused mldonkey group

groups 

print groups of logged-in user

passwd 

change own password

useradd 

add new mldonkey user/change user password

usercommit 

change user specific commit directory

userdel 

remove a mldonkey user

userdgroup 

change user default group

userdls 

change number of allowed concurrent downloads

usergroupadd 

add a group to a mldonkey user

usergroupdel 

remove a group from a mldonkey user

usermail 

change user mail address

users 

print users

whoami 

print logged-in user name

Temporary solution for restriction of access to a administration, if you have MLDonkey and webserver installed on same machine:

If you need to look only a condition of yours downloads, without access to administration, you should place on your webserver following page (for example 1.php named):

   <?php
      $adr<code>'http://127.0.0.1:4080/submit?q</code>vd';
      $screen=file($adr);
      $k=0;
      $m=sizeof($screen);
      for ($i<code>$k; $i<</code>$m; $i++) {
   	echo $screen[[$i]];
      }
   ?>

Now you can see a condition of download in url http://your.server.name/1.php if you put 1.php to the root of your server.

Note: You need webserver with support php installed. Look http://www.apache.org/ for example.

Note2: You will see some admin's button, but they will not work! I think for the time decision it's normally

Note3: I think that late PHP addition spoils that page (on an already too complex matter).

Comments on a new multi-user system

Most of the stuff mentioned in older version of this article are implemented in MLDonkey.
See [multiuser.txt] for details.

To-Do

• Could allow integration with existing user/group systems, like phpbb, wikis, content management systems, with a simple conversion script of users and groups
• GUI protocol:
  • • Just like paused and queued files, the user can then choose to see only files of a specific group in the gui (if the gui supports this), but, just like paused and queued files the decision on what files the user is able to view-filter must not be made by the core.
  • Only send sources that are attached to a file to which the user has access
    • If user "bob" only has 1 download and connects via the gui protocol, but mldonkey is downloading 1000 files, the core must not send the sources for the other files over the gui protocol (unless they are friends)

• Extensions
  • Potentially groups could have access flags in the future to add more functionality
    • Example: "groupA" has flag "notification", "groupB" does not
      • When FileX completes and is in groupA, notification email is sent to all members, FileY completes and is in groupB, but no noticiation mail is sent to the group members (only owner). This allows flexibility at the group level.
        • Something similar can be done for a flag that indicates a symlink to the newly commited file should be created all group member's commit directories, or to allow all users in the group to cancel the file ...

---

Languages:  English  • Русский