Wrong access control after installation. #1762

New Issue

GiteaMirror · 2025-11-02T04:12:33-06:00

GiteaMirror commented

2025-11-02 04:12:33 -06:00

Originally created by @fduxiao on GitHub (May 7, 2018).

I've found that after I chose Require Sign-In to View Pages and installed gitea, anyone could access the website without logging in. See my example at https://test-skgbdmorhk.now.sh. You could see the source code here. You may also have a check of the configure with username root and password 123456 (Don't ruin it !!!)
Everything will work if I restart the service (I tried on another server. After I restarted the service, it worked well.) or build the docker image with a previous config (which I also included in the source code). I found this because I tried to setup a private doc-site and I found I could hardly keep them private (since now could not restart a deployment), or I could not specify the correct url (since I could not tell the url before the service is deployed) (See now).
I have to rebuilt the docker for now with current code (now demand exact one EXPOSE) but the same issue occurred with the docker image of ID c3220cdfd801.
I think this should be an issue. Do I miss something?

Originally created by @fduxiao on GitHub (May 7, 2018). I've found that after I chose `Require Sign-In to View Pages` and installed gitea, anyone could access the website without logging in. See my example at https://test-skgbdmorhk.now.sh. You could see the source code [here](https://zeit.co/fduxiao/test/skgbdmorhk/source). You may also have a check of the configure with username `root` and password `123456` (Don't ruin it !!!) Everything will work if I restart the service (I tried on another server. After I restarted the service, it worked well.) or build the docker image with a previous config (which I also included in the source code). I found this because I tried to setup a private `doc-site` and I found I could hardly keep them private (since `now` could not `restart` a deployment), or I could not specify the correct url (since I could not tell the url before the service is deployed) (See [now](https://now.sh)). I have to rebuilt the docker for now with current code (`now` demand exact one `EXPOSE`) but the same issue occurred with the docker image of ID c3220cdfd801. I think this should be an issue. Do I miss something?

GiteaMirror added the type/bug label 2025-11-02 04:12:33 -06:00

GiteaMirror closed this issue

2025-11-02 04:12:33 -06:00

GiteaMirror commented

2025-11-02 04:12:34 -06:00

@stale[bot] commented on GitHub (Jan 27, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Jan 27, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:12:34 -06:00

@bsilva-bentlabs commented on GitHub (Dec 15, 2020):

Please fix. I just installed Gitea for an organization and I'm pretty sure they're going to disallow it with this bug.

Thanks,
Brad

@bsilva-bentlabs commented on GitHub (Dec 15, 2020): Please fix. I just installed Gitea for an organization and I'm pretty sure they're going to disallow it with this bug. Thanks, Brad

GiteaMirror commented

2025-11-02 04:12:34 -06:00

@bsilva-bentlabs commented on GitHub (Dec 15, 2020):

Please fix. I just installed Gitea for an organization and I'm pretty sure they're going to disallow it with this bug.

Thanks,
Brad

Hmm... It appears this only occurs on first start of the server. So far, every subsequent restart of the service or server reboots, the feature behaves as expected.

so, this is of far lower importance than I'd first thought.

Brad

@bsilva-bentlabs commented on GitHub (Dec 15, 2020): > Please fix. I just installed Gitea for an organization and I'm pretty sure they're going to disallow it with this bug. > > Thanks, > Brad Hmm... It appears this only occurs on first start of the server. So far, every subsequent restart of the service or server reboots, the feature behaves as expected. so, this is of far lower importance than I'd first thought. Brad

GiteaMirror commented

2025-11-02 04:12:34 -06:00

@techknowlogick commented on GitHub (Dec 15, 2020):

This is resolved in 1.14-dev.

@techknowlogick commented on GitHub (Dec 15, 2020): This is resolved in 1.14-dev.

GiteaMirror referenced this issue

2025-11-02 12:00:53 -06:00

[PR #1762] [MERGED] fix: #1757 fix set MAX_CREATION_LIMIT as zero. #16039

Sign in to join this conversation.