Multi-user web interface.

[meettya]

I changed my torrentflux-b4rt to transmission-daemon&WEB gui (I use old desktop as big NAS)
WOW!
I totally loved in So nice, and clever, and ... WOW!
But I have some trouble.
My wife wants another one for herself!

I read on forum - somebody use another one daemon with another one settings, but i think its not so fun

Is it hard - to do multi-user interface?
I see its enough : pair "user":"pass", detached "torrents dir"&"watch-dirs", and all.

[gabel]

I would looove to see this feature. And meettya is right. All we need is a User/Path and a bit changed gui to show the torrents by user or for admins show all torrents, but grouped by user... it would be great to have such feature.

[KyleK]

Although I'm not a dev, I can tell you right now: This is not gonna happen anytime soon (if ever). This would be useful only for a very small group of people, and the efforts far outweigh the usefulness of such a feature.
Besides, why can't your wife use the same account as you do?

Anyway, you CAN run two transmission-daemons at once. Just create two different config files with different download paths and different RPC port and you're good to go.

[gabel]

It's not about a wife It's about a bunch of up to ten ppl using one linux pc as torrent client. There are solutions like torrentflux, torrentflux b4rt (works with transmission but only on old versions) and Azureus remote client but there is no solution for transmission itself.

It wouldn't be that hard to create a solution but i'm not into the project...

What is missing in WebUI?

• Multi-User Login
• user management - already exists for one user
• rights management - which user can see only the torrents of himself or all torrents (groups could be nice later) - a user access already exist and just need to be enhanced for multiple users
• a custom path needs to be set for every single user ( transmission-download-root/user1, transmission-download-root/user2, ...) - the plugin just have to add the username at the end of the common download path
• space usage for the user paths (e.g. User1: 15 GB, User2: 52 GB, Overall: 102 of 160 GB used)

These features aren't so hard to implement in my opinion and where done in other torrentclients before. But I prefer transmission for its low cpu load and stable state (current versions).

[Rarok]

Have you discovered any way to run a "multiuser" transmission?

I'm not a power user so I don't know how to run two transmission-daemons?

I used torrentflux but I would like to use transmission because the low cpu load.

I think even it could be done having a transmission running for each user, with this it could have multiuser, quotas and different paths.

[kondado]

Although this topic is quite old, maybe anyone else will stumble across this in a future time...

So the answer is on these websites:

http://www.dd-wrt.com/wiki/index.php/Tr ... ion_daemon

viewtopic.php?f=2&t=9810

https://trac.transmissionbt.com/wiki/Co ... Parameters

I won't explain any of those steps, if you don't know how to apply them this is probably not for you. (Or you'll have to spend time learning, like everybody else does. )

[judgey]

Multi-user web interface will be one of the top things people are after. I have seen it asked on most torrent client sites as most people have this on there servers and want other users to login without having to have muti installs.


So saying people dont need or want this is not rly true.

[lazybones]

I bet this could be done leveraging tags and adding the ability to have more than one username/password.

You could create a hidden tag on each torrent with the users name and then in the ui only show that user their torrents.

[Richy_T]

IMO, the whole transmission-daemon thing should be multi-user from the ground-up. This is *nix, not windows 3.1. But since I'm the only one that uses it in my household, it's not my itch to scratch.

[strites]

Hello, this is my first post

I took a look this night at source codes, watching for a way to implement this.

Because of some booze I got for the evening, I may have took this all wrong, but here's my 2 cents:

Intended plan:
Multi-user things are only for remote operation. No change in the rpc syntax should happen. Users are defined by an UID, a login and a password. In local mode, the UID will be 0, the "administrator account" which uses normal RPC log in in the settings, that will have access to every torrent.

Passes to implement:

1. Add a UID list in tr_torrent struct.
   initially I thought for an int, but a list may be used in future, watching the "A anb B download the same file" case.
2. add an UID int correspondance with every authed session
   (I thought using the X-Transmission-Session-Id field, but it seems made global, so there is maybe need to implement something new here)
3. Make torrent listings show only torrents which have the session-UID in the tr_torrent->uid list (in case the session-uid is 0, ignore the filtering)
4. Make adding remote torrents inherit the session-uid in their tr_torrent->uid (0 for local or admin-torrent)
5. Implementation of a Login/user dictionary with UID association. (for the moment the dic will be UID:login:password lists, other options after)

This will be the first phase. At this moment, no custom user download dirs are configured. Only for showing the list.
This can be configured in the same fashon of the point 4 of the first phase.

Configuration:
at first I see an offline configuration method: at every start the userlist is read.

Resume:
adding an UID field to the resume file is needed, but at first an "all-resumed-uids-are-0" method may be used.


So, for the moment:

the thing more "hard" is the point 2.
In fact the authentication pass is made using http basic authentication, so it's sent with every request.
Probably we may hook up the rpc-server.c around handle_request() and make the Auth Basic [b16encodedshit] association....

[lpic.lt]

any movement on this thread?

[Kdobrev]

Any news here?
How the multi user is going?

[killemov]

Ah, you necro-posted on this topic. As you can tell from the dates on the previous posts: It is not going. The use-case is extremely niche and the proposed changes to the software are hard and intrusive. The easiest solution would be to run a separate daemon with a separate configuration for each user.

Update, check this out: Multi-user Transmission server setup