RFC: Single-User Mode #5217

@spadino commented on GitHub (Apr 9, 2020):

I'm searching for the same. +1

@spadino commented on GitHub (Apr 9, 2020): I'm searching for the same. +1

GiteaMirror commented

@spadino commented on GitHub (Apr 9, 2020):

Btw, @RealOrangeOne, how to you use this task you coded? I also use cgit - by now, its root is on one organization, the one I want to let public - but I'm curious to test your approach.... ;)

@spadino commented on GitHub (Apr 9, 2020): Btw, @RealOrangeOne, how to you use this task you coded? I also use cgit - by now, its root is on one organization, the one I want to let public - but I'm curious to test your approach.... ;)

GiteaMirror commented

@RealOrangeOne commented on GitHub (Apr 9, 2020):

Offtopic, but script works by scraping the public API of the instance, and building a cgit repos list, and having cgit serve from that. this might be a slightly better example.

@RealOrangeOne commented on GitHub (Apr 9, 2020): Offtopic, but script works by scraping the public API of the instance, and building a cgit repos list, and having cgit serve from that. [this](https://github.com/RealOrangeOne/infrastructure/blob/master/ansible/roles/docker/files/gitea/docker-compose.yml#L68) might be a slightly better example.

GiteaMirror commented

@guillep2k commented on GitHub (Apr 10, 2020):

I think the easiest workaround would be creating an organization with name 'x' and transferring all repos to that organization.

@guillep2k commented on GitHub (Apr 10, 2020): I think the easiest workaround would be creating an organization with name 'x' and transferring all repos to that organization.

GiteaMirror commented

@RealOrangeOne commented on GitHub (Apr 10, 2020):

That would also work, and is actually far nicer than my current approach, but still a bit of a bodge

@RealOrangeOne commented on GitHub (Apr 10, 2020): That would also work, and is actually far nicer than my current approach, but still a bit of a bodge

GiteaMirror commented

@guillep2k commented on GitHub (Apr 10, 2020):

Also:

git.mylongdomain.com/mylonghandle/mylongusername.com

should be

git.mylongdomain.com/mylonghandle/mylongrepositoryname

Why longusername and why .com?

@guillep2k commented on GitHub (Apr 10, 2020): Also: ``` git.mylongdomain.com/mylonghandle/mylongusername.com ``` should be ``` git.mylongdomain.com/mylonghandle/mylongrepositoryname ``` Why `longusername` and why `.com`?

GiteaMirror commented

@RealOrangeOne commented on GitHub (Apr 11, 2020):

Why longusername and why .com?

Typo. My point still stands though, the URLs aren't the nicest.

@RealOrangeOne commented on GitHub (Apr 11, 2020): > Why longusername and why .com? Typo. My point still stands though, the URLs aren't the nicest.

GiteaMirror commented

@stale[bot] commented on GitHub (Jun 10, 2020):

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale[bot] commented on GitHub (Jun 10, 2020): This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

GiteaMirror commented

@RealOrangeOne commented on GitHub (Jun 10, 2020):

This is still definitely an issue, and IMO still really nice to have!

(Obviously probably isn't the most urgent and highly-demanded request in the world!)

@RealOrangeOne commented on GitHub (Jun 10, 2020): This is still definitely an issue, and IMO still really nice to have! (Obviously probably isn't the most urgent and highly-demanded request in the world!)

GiteaMirror commented

@severinkaderli commented on GitHub (Sep 2, 2020):

I'm also looking for something like this. I'm using Gitea only for myself and shorter URLs would be a nice thing to have.

@severinkaderli commented on GitHub (Sep 2, 2020): I'm also looking for something like this. I'm using Gitea only for myself and shorter URLs would be a nice thing to have.

GiteaMirror commented

@myitcv commented on GitHub (Sep 23, 2020):

For anyone else arriving at this issue, I had the same requirement and have solved it using a reverse proxy (nginx in my case) in front of my gitea instance. My setup looks roughly like this:

http {
  server {
    listen              443 ssl;
    server_name         my.domain;

    ssl_certificate     /ssl/cert.pem;
    ssl_certificate_key /ssl/key.pem;
    location / {
      proxy_http_version 1.1;
      proxy_set_header Host $host;
      proxy_ssl_server_name on;
      proxy_set_header X-Forwarded-Host $host:$server_port;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://gitea:3000/x/;
    }
  }

  server {
    listen              443 ssl;
    server_name         api.my.domain;

    ssl_certificate     /ssl/cert.pem;
    ssl_certificate_key /ssl/key.pem;
    location / {
      proxy_http_version 1.1;
      proxy_set_header Host $host;
      proxy_ssl_server_name on;
      proxy_set_header X-Forwarded-Host $host:$server_port;
      proxy_set_header X-Forwarded-Server $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://gitea:3000/;
    }
  }
}

(I'm no nginx expert so it's entirely possible the above could be simplified).

Notice how with the server my.domain, all requests to location / get routed to http://gitea_3000/x/. I separated out api.my.domain in order that API traffic is directed at http://gitea:3000/

@myitcv commented on GitHub (Sep 23, 2020): For anyone else arriving at this issue, I had the same requirement and have solved it using a reverse proxy (nginx in my case) in front of my `gitea` instance. My setup looks roughly like this: ``` http { server { listen 443 ssl; server_name my.domain; ssl_certificate /ssl/cert.pem; ssl_certificate_key /ssl/key.pem; location / { proxy_http_version 1.1; proxy_set_header Host $host; proxy_ssl_server_name on; proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://gitea:3000/x/; } } server { listen 443 ssl; server_name api.my.domain; ssl_certificate /ssl/cert.pem; ssl_certificate_key /ssl/key.pem; location / { proxy_http_version 1.1; proxy_set_header Host $host; proxy_ssl_server_name on; proxy_set_header X-Forwarded-Host $host:$server_port; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass http://gitea:3000/; } } } ``` (I'm no nginx expert so it's entirely possible the above could be simplified). Notice how with the server my.domain, all requests to location `/` get routed to http://gitea_3000/x/. I separated out api.my.domain in order that API traffic is directed at http://gitea:3000/

GiteaMirror commented

@spadino commented on GitHub (Sep 23, 2020):

Pretty clever, thanks!

@spadino commented on GitHub (Sep 23, 2020): Pretty clever, thanks!

GiteaMirror commented

@stfnx commented on GitHub (Dec 16, 2020):

I am looking for the same feature.

This could be a setting in app.ini to run Gitea in "single user mode".
Then all repositories are available via domain.tld/repo.

The only thing to check is if there are any organisations named repo so that it doesn't collide.
But in real world I guess this shouldn't happen too often?

PS: Am I right that the nginx proxy would only work for HTTP, but not for SSH?

@stfnx commented on GitHub (Dec 16, 2020): I am looking for the same feature. This could be a setting in `app.ini` to run Gitea in "single user mode". Then all repositories are available via `domain.tld/repo`. The only thing to check is if there are any organisations named `repo` so that it doesn't collide. But in real world I guess this shouldn't happen too often? PS: Am I right that the nginx proxy would only work for HTTP, but not for SSH?

GiteaMirror commented

@m455 commented on GitHub (May 30, 2021):

This could be a setting in app.ini to run Gitea in "single user mode".
Then all repositories are available via domain.tld/repo.

I would absolutely love this feature. It's similar to how cgit or gitweb is. I would love a single user mode :D

I wonder if you could somehow check if domain.tld/repo.git works if someone tried to navigate to domain.tld/repo, that way it could check if it's a repo, user, or org. I don't know much about this though haha.

@m455 commented on GitHub (May 30, 2021): > This could be a setting in app.ini to run Gitea in "single user mode". > Then all repositories are available via domain.tld/repo. I would absolutely love this feature. It's similar to how cgit or gitweb is. I would love a single user mode :D I wonder if you could somehow check if `domain.tld/repo.git` works if someone tried to navigate to `domain.tld/repo`, that way it could check if it's a repo, user, or org. I don't know much about this though haha.

GiteaMirror commented

@tarasis commented on GitHub (Jan 21, 2022):

I would also echo call for single user mode. My "fix" for the moment is redirecting /user/sign_up in the web server, after I created my account.

I don't mind having a long url domain/user/repo, I just want an easy way to prevent others from signing up like a setting that just disables the signup page.

@tarasis commented on GitHub (Jan 21, 2022): I would also echo call for single user mode. My "fix" for the moment is redirecting `/user/sign_up` in the web server, after I created my account. I don't mind having a long url domain/user/repo, I just want an easy way to prevent others from signing up like a setting that just disables the signup page.

GiteaMirror commented

@RealOrangeOne commented on GitHub (Jan 21, 2022):

like a setting that just disables the signup page

There's already a DISABLE_REGISTRATION setting, see https://docs.gitea.io/en-us/config-cheat-sheet/.

This is something different.

@RealOrangeOne commented on GitHub (Jan 21, 2022): > like a setting that just disables the signup page There's already a `DISABLE_REGISTRATION` setting, see https://docs.gitea.io/en-us/config-cheat-sheet/. This is something different.

GiteaMirror commented