Multi users multi repositories

[yohanakh]

I want to use ungit as a web server that multiple users can use. Each user will work a different working directory/repository.

Is this possible with the current implementation? How can i configure users/auth ?

Thanks

[Ajedi32]

A lot of people seem to want to use ungit this way. I guess I can see why that is, given the nice web interface that Ungit provides. This isn't something that's "officially" supported afaik, but maybe it should be?

[jung-kim]

One of the advantages of git, not ungit, is to allow users to work in their own environment and send diffs to the repo. With this beautiful technology, why would you want to have multiple people working on a shared server? Ungit can be used via share server by multiple people with some fixes but I can't help but to feel that this use case is a step backward in software dev evolution.

[Ajedi32]

That's a good point. Really all you need to have a "multi-user repository" with ungit is a git server and ungit on every client machine. Does this desire for shared access to ungit on the server stem from a lack of understanding of how git works, or is there some use-case we're overlooking here?

[yohanakh]

Well i am creating a web server that enables multi users to create local git repositories and then i found out about ungit and wounder if i can use it with my web server. So in my case, there are multiple users with one or more repositories for each. I am not familiar with NodeJS. Is this possible?

[Ajedi32]

Ah, so by "local" you mean "stored on the user's computer", correct?

If so, you can't really do that by setting up ungit on a remote server. Ungit relies on the "server" component running on the same machine the repository is on, so if you want to let users create local repositories with ungit, they'll all have to be running their own copy of ungit, just like with regular desktop software.

[yohanakh]

Sorry i meant on the local server meaning the machine that runs the web server.

[Ajedi32]

Ah okay. So like a web UI for setting up remote git repositories? Have you looked into GitLab? It seems far better suited for that sort of thing than Ungit.

[yohanakh]

Yeah i read about GitLab but i think it does not match my requirements. I don't need a git server. As you said, i need a webui. The use case is: User1 login -> clone his remote git repo -> make changes -> want to commit and push the changes back to the remote git repo. The user will do all the above using a webui. He does not has any access to the machine. Is it hard to implement with your ungit? Thanks

[Ajedi32]

Ah okay, in that case ungit should theoretically be able to handle the "clone remote git repo" and the "commit and push the changes back" parts of that workflow. Again though, ungit is currently not designed with that use case in mind. The "make changes" and "login" portions of that workflow would have to be handled by your own custom code. Ungit isn't a text editor, and it is currently designed with the assumption that the person running the ungit web server is the one and only user of the application.

[Ajedi32]

Also, it sounds like you may want to look at https://c9.io/ and http://root-project.org/2014/07/09/work/ungit-on-cloud9/

See also #494 and #313.

[yohanakh]

That's cool but it does not fit my needs either! My webserver is not only an editor.

[Ajedi32]

Well, assuming you run one instance of ungit for each user, and only allow access to the ungit server for any particular user after authentication, you should probably be fine. Then again though, there might be security issues with trusting the client in a setup like that; I don't know enough about ungit's internals to say for sure one way or the other on subject.

You'd have to implement authentication yourself; HTTP basic auth could probably be set up at the web server level. Depending on your exact setup, #313 might also be important to you.

All in all though it doesn't sound impossible; there's nothing really blocking you from doing this AFAIK.

[45413]

I would like to add a use case where this would absolutely be a need feature. I work for a small software development company. All of our users are operating on windows machines, but our application development is preformed on a remote (headless) Linux development box via putty or other SSH clients. This is due to the significant licensing cost of our application engine as well as the tight coupling of the run-time environment, source code, and database (anyone who has built or maintains old school mainframe systems knows what i am talking about).

So what we currently do is have our developers login via SSH to our Linux development host. Each have their on working repository (instance of the application). Source code is modified using native/text based editors/IDE, then compiled and run remotely. While this works fine for code development and testing, many of our developers prefer the benefits of a git GUI for staging, committing files as well reviewing the git log, or checking out branches. Currently we utilize git gui, or alternative git UI (SmartGit, gitEye, git-cola) running over X11. While this works for the most part, any one who has experience using X11 over a remote connection be it directly over SSH or through a VPN (especially slow DSL or mobile WWAN, as many remote/traveling employees do) this can have significant performance limitations. Simple operations such as checking out a branch or review and staging files for a commit can take minutes (upwards of 5-10), where the same operation if ungit takes mere seconds.

I have setup a few test cases using multiple instances of ungit running as a service under each developer user which works for the most part but this requires unique ports for each instance/user. However this exposes significant security issues as anyone with access to that instance can make commit/changes to another developers repo. While I can mitigate this risk with unique user authentication with each running instance this is still not bulletproof. If the user authentication currently available in ungit was extended to also allow limitations on which directories/repositories the authenticated user has access to, then we theoretically run a single instance of ungit using a service user (lets call him ungit, cause why not). we could then set the group ownership for all developer repositories to allow the ungit service account to preform git operations while still isolating the developers working in Liunx from directly modifying each others repositories/working files.

[Ajedi32]

Yeah, that seems like a pretty reasonable use case. I've been doing something similar with developing inside a VM, but as each developer can have their own VM I haven't had to worry about supporting multiple users.

One question though: when you say "Source code is modified using native/text based editors/IDE, then compiled and run remotely." does that mean that each developer has a local copy of the source code which is then pushed to the server and complied whenever they make changes? If so, why would they not just run git/ungit on their local box?

[45413]

No by native I meant code editors on the Linux server such as vim or application specific editors that are packaged with our development run-time environment. I have also already suggested to management that they just keep the source local, commit, and push it to the remote server, then compile on a git push hook but apparently that concept is to difficult and have to much "overhead" and would slow down development. Ironic since all developers are complaining each day how slow the GUIs are when working remotely.

[linquize]

Run 2 instances of ungit with 2 different ports.

[45413]

@linquize - this has already been suggested and per my original comment this is doable but has significant security and overhead drawbacks.

[jung-kim]

I'm not convinced. Can you clarify what you are asking?

And as far as aforementioned security problem. Ungit has a config where filter incoming traffics via ip address. You can use that and have it so that port 8080 accepts ip1 and 8081 accepts ip2 and so on. Frankly, this is a very limited solution and it has its own problem. In order for ungit to properly handle multi users on a single server, we would have to implement logins at ungit's end.

You are more then welcome to submit pull requests but this seems to be a large overhead for a small interest that seems to be deviating from how git is meant to be used.

[yebrahim]

Another use case for this is running ungit for a single user in a docker container environment where git never was initialized to begin with. Even though it's not a shared environment, the user still needs to do git config for the first time, and if they don't have access to a command line, they'd need ungit to expose this, maybe as a setting.

[jung-kim]

Please open another ticket for configuring git user name and emails as I think that is a valid configuration changes changes. Meanwhile, I think you can set them up in the .bashrc or however your OS initialize global variables.

However, if you are asking for different git user name and email per different user. I think we would have to implement some kind of logins or validating each user, which we can do but my entire argument is that I'm not convinced that this overhead is worth benefit it gives us when git is meant to work in distributed environment.

For example, you can have each users spawn their own ungit docker and have them push remote branches.

[yebrahim]

Sure, opened #817.

FWIW, in my specific use case, each user does have their own docker container, but the container's environment is kept generic enough and should not know about the user's info, so that can't be passed as a variable.

[jung-kim]

I guess you could bake your own ungit docker container with private keys and git configs, although I would agree that it seems barbaric. Or you could have network hard drive volume per user with ungit and config on it that can be mounted.

[yebrahim]

I only offer the docker image, users create their own containers out of it, so nothing can be saved there. Same assumption for the network volume, they get a vanilla environment, and customize it the way they want.