Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/serv: initalize session settings properly #6916

Closed
wants to merge 1 commit into from

Conversation

nopjmp
Copy link

@nopjmp nopjmp commented May 12, 2019

This should fix #5478 and with REQUIRE_SIGNIN_VIEW=true lfs auth errors

Without this, ssh git@<domain> git-lfs-authenticate <repo> download will not return user claim and will cause an authentication error. cmd/dump also uses this same pattern.

gitea/cmd/dump.go

Lines 62 to 63 in e1fcd6b

setting.NewContext()
setting.NewServices() // cannot access session settings otherwise

I'm not sure, but it also looks like it needs to be done here?

gitea/cmd/cmd.go

Lines 39 to 48 in e1fcd6b

func initDBDisableConsole(disableConsole bool) error {
setting.NewContext()
models.LoadConfigs()
setting.NewXORMLogService(disableConsole)
if err := models.SetEngine(); err != nil {
return fmt.Errorf("models.SetEngine: %v", err)
}
return nil
}

This should fix go-gitea#5478 and with REQUIRE_SIGNIN_VIEW=true lfs auth errors
@lunny
Copy link
Member

lunny commented May 12, 2019

No, I don't think gitea serv needs that services. gitea serv will call internal URL to do all requests.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label May 12, 2019
@nopjmp
Copy link
Author

nopjmp commented May 12, 2019

@lunny then should settings be initialized in NewContext instead? I'm not getting settings in the git-lfs-authenticate. It works now on my server with this customization. What would be a better way?

@lunny
Copy link
Member

lunny commented May 12, 2019

LFS has initalized in NewContext. See https://github.com/go-gitea/gitea/blob/master/modules/setting/setting.go#L679

@nopjmp
Copy link
Author

nopjmp commented May 12, 2019

if requestedMode == models.AccessModeWrite || repo.IsPrivate || setting.Service.RequireSignInView {

LFS also depends on other settings being in place to know what claims the jwt token needs. It's initialized here:

func newService() {
sec := Cfg.Section("service")
Service.ActiveCodeLives = sec.Key("ACTIVE_CODE_LIVE_MINUTES").MustInt(180)
Service.ResetPwdCodeLives = sec.Key("RESET_PASSWD_CODE_LIVE_MINUTES").MustInt(180)
Service.DisableRegistration = sec.Key("DISABLE_REGISTRATION").MustBool()
Service.AllowOnlyExternalRegistration = sec.Key("ALLOW_ONLY_EXTERNAL_REGISTRATION").MustBool()
Service.EmailDomainWhitelist = sec.Key("EMAIL_DOMAIN_WHITELIST").Strings(",")
Service.ShowRegistrationButton = sec.Key("SHOW_REGISTRATION_BUTTON").MustBool(!(Service.DisableRegistration || Service.AllowOnlyExternalRegistration))
Service.RequireSignInView = sec.Key("REQUIRE_SIGNIN_VIEW").MustBool()
Service.EnableReverseProxyAuth = sec.Key("ENABLE_REVERSE_PROXY_AUTHENTICATION").MustBool()

@lunny
Copy link
Member

lunny commented May 12, 2019

@nopjmp you are right. But I think we also need to load minimal settings.

@nopjmp
Copy link
Author

nopjmp commented May 12, 2019

We could always just include the user claims in the jwt token regardless of the repository setting and access mode, if the user is using an authenticated ssh key. I don't think that's unreasonable, but it could increase the load on larger git servers theoretically.

Alternatively, NewContext could initialize the setting.Service.RequireSignInView from the configuration file.

@zeripath
Copy link
Contributor

I'm going to suggest we do the compete opposite - make serv and hook as dumb as possible and move almost all their logic on to a private URL endpoint.

This should be faster as there won't be the back and forth between the Gitea web service and these processes, and if there is a deadlock it should be easier to manage. We will also be able to kill the serv and hook logs and make better logging as it will use the default Gitea logs.

@nopjmp
Copy link
Author

nopjmp commented May 18, 2019

I spent some time thinking and agree with @zeripath on this. I'm going to keep my local hack in my repo for now since I need this to work on my instance.

Additionally, I'll convert this over to an issue to make tracking it easier as I should have done in the first place.

@zeripath
Copy link
Contributor

zeripath commented May 18, 2019

Btw I'm currently in the process of doing this.

The above was merged as #6993.

@lafriks lafriks removed this from the 1.9.0 milestone May 19, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. type/bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

LFS pull fails on public SSH-cloned repo
6 participants