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

/admin/default-hooks/gitea/new 500 #22154

Closed
captainstdin opened this issue Dec 18, 2022 · 4 comments
Closed

/admin/default-hooks/gitea/new 500 #22154

captainstdin opened this issue Dec 18, 2022 · 4 comments
Labels
issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea

Comments

@captainstdin
Copy link

Description

image

image

verversion: 1.18.0+rc1

Gitea Version

1.18.0+rc1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker run -it \
--name=gitea \
-p443:3000 \
-p127.0.0.1:2222:22 \
-e USER_UID=1001 \
-e USER_GID=1000 \
-v `pwd`/public:/data/gitea/public \
-v `pwd`/templates:/data/gitea/templates \
-v `pwd`/data:/data/gitea \
-v `pwd`/log:/data/gitea/log \
-v `pwd`/custom/conf/app.ini:/data/gitea/conf/app.ini \
-v /home/git/.ssh/:/data/git/.ssh \
gitea/gitea:latest

Database

SQLite

@zeripath
Copy link
Contributor

It would be helpful if the provided logs were as text rather than a screenshot, as the screenshot has slightly cut off the salient part of the error message.

From the bit I can tell there is a template error with some property HeaderAuthorization being missing on the some struct provided to the template (likely a struct named hook given the context)

@zeripath
Copy link
Contributor

zeripath commented Dec 18, 2022

<input id="authorization_header" name="authorization_header" type="text" value="{{.Webhook.HeaderAuthorization}}"{{if eq .HookType "matrix"}} placeholder="Bearer $access_token" required{{end}}>

Which was added in #20926 - but this is 1.19 only...

OUTDATED

The erroring router is here:

// WebhooksNew render creating webhook page
func WebhooksNew(ctx *context.Context) {
ctx.Data["Title"] = ctx.Tr("repo.settings.add_webhook")
ctx.Data["Webhook"] = webhook.Webhook{HookEvent: &webhook.HookEvent{}}
orCtx, err := getOrgRepoCtx(ctx)
if err != nil {
ctx.ServerError("getOrgRepoCtx", err)
return
}
if orCtx.IsAdmin && orCtx.IsSystemWebhook {
ctx.Data["PageIsAdminSystemHooks"] = true
ctx.Data["PageIsAdminSystemHooksNew"] = true
} else if orCtx.IsAdmin {
ctx.Data["PageIsAdminDefaultHooks"] = true
ctx.Data["PageIsAdminDefaultHooksNew"] = true
} else {
ctx.Data["PageIsSettingsHooks"] = true
ctx.Data["PageIsSettingsHooksNew"] = true
}
hookType := checkHookType(ctx)
ctx.Data["HookType"] = hookType
if ctx.Written() {
return
}
if hookType == "discord" {
ctx.Data["DiscordHook"] = map[string]interface{}{
"Username": "Gitea",
}
}
ctx.Data["BaseLink"] = orCtx.LinkNew
ctx.HTML(http.StatusOK, orCtx.NewTemplate)
}

We can see that the .Webhook property is set to a models/webhook.Webhook struct and if we look at:

// HeaderAuthorization returns the decrypted Authorization header.
// Not on the reference (*w), to be accessible on WebhooksNew.
func (w Webhook) HeaderAuthorization() (string, error) {
if w.HeaderAuthorizationEncrypted == "" {
return "", nil
}
return secret.DecryptSecret(setting.SecretKey, w.HeaderAuthorizationEncrypted)
}

We see that there is very definitely a function on that struct for header authorization.

~~But note the comment on the function - which I think may be the cause of all of the problems. I suspect this should just be a pointer receiver and at worst we change the router to send a pointer to ctx.Data. ~~

The likely underlying problem is a GOtcha to do with casting as interface{} which I suspect does an implicit pointer reference.

There is no HeaderAuthorization in 1.18 - you're using a template from 1.19/main in 1.18 and that is why you have this problem.

@zeripath zeripath modified the milestone: 1.18.0 Dec 18, 2022
@zeripath zeripath added reviewed/invalid issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea and removed type/bug labels Dec 18, 2022
@captainstdin
Copy link
Author

captainstdin commented Dec 18, 2022

There is no HeaderAuthorization in 1.18 - you're using a template from 1.19/main in 1.18 and that is why you have this problem.

Yes, I got it , you are right。thinks

When I replace the setting.tmpl file with the template of v1.18 library, everything returns to normal,

In fact, the problem is caused by the use of github's main branch template

by the way , gitea/gitea:latest , Is it 1.18 actually ? and

If I want to render the domain , I should use the built-in global template variable of gitea?
{{AppUrl}} Will carry protocal://xxx

@zeripath
Copy link
Contributor

The docker tag gitea/gitea:latest is the latest release or release-candidate. gitea/gitea:dev represents the last successful build from the main branch.

In the templates, you're correct that {{AppUrl}} will be the set-up application url.

BTW you can use the gitea embedded command to extract any built-in templates rather than risk downloading the incorrect version for your current version of gitea.

@go-gitea go-gitea locked and limited conversation to collaborators May 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/not-a-bug The reported issue is the intended behavior or the problem is not inside Gitea
Projects
None yet
Development

No branches or pull requests

4 participants