Web hooks not successful: Invalid href value provided.

[bkraul]

• Gitea version (or commit ref): ad1b6d4
• Git version: 1.12.0+dev-130
• Operating system: Docker (Ubuntu 18.04 LTS host)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

All webhooks have begin to fail with the following response:

Headers

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Origin: *
Cache-Control: no-store
Connection: keep-alive
Content-Type: application/json
Date: Mon, 20 Jan 2020 18:00:59 GMT
Pragma: no-cache
Server: nginx/1.17.5
Strict-Transport-Security: max-age=31536000
Vary: Accept-Encoding
X-Instance-Id: kywEfEQGjr4NXbNts
X-Ratelimit-Limit: 50
X-Ratelimit-Remaining: 49
X-Ratelimit-Reset: 1579543319854
X-Xss-Protection: 1

Body

{"success":false,"error":"Invalid href value provided"}

The webhook URL has not changed, and it was working properly before.

Screenshots

[jolheiser]

I see you blurred the text fields, but I suspect those are the relevant part to this bug.

Can you give us an example? You can replace it with a spoof message, but just so we can see the structure?

[bkraul]

I changed the domain name, and some of the letters on the token:

Headers

Request URL: https://hooks.mydomain.com/hooks/1tzWu8yGGZ4PELbNb/3QNWPwufcyZD8N6wAJyHcZ2LAxH5xecnKJuWJe8ZvC9ZE8En
Request method: POST
Content-Type: application/json
X-GitHub-Delivery: 7fc692b1-cac9-441a-bb22-ae79d80f00b0
X-GitHub-Event: push
X-Gitea-Delivery: 7fc692b1-cac9-441a-bb22-ae79d80f00b0
X-Gitea-Event: push
X-Gitea-Signature: 
X-Gogs-Delivery: 7fc692b1-cac9-441a-bb22-ae79d80f00b0
X-Gogs-Event: push
X-Gogs-Signature: 

Content

{
  "channel": "#internal-commits",
  "text": "[\u003chttps://git.mydomain.com/org/Project.SubProject|epg/Project.SubProject\u003e:\u003chttps://git.mydomain.com/org/Project.SubProject/src/branch/master|master\u003e] \u003chttps://git.mydomain.com/org/Project.SubProject/compare/e182e39f16b75d31513ca0122ec5b175b904b573...8c847a9f3a13b91e03538594934630897e8deb91|1 new commit\u003e pushed by bkraul",
  "username": "",
  "icon_url": "",
  "unfurl_links": 0,
  "link_names": 0,
  "attachments": [
    {
      "fallback": "",
      "color": "",
      "title": "",
      "title_link": "",
      "text": "\u003chttps://git.mydomain.com/org/Project.SubProject/commit/8c847a9f3a13b91e03538594934630897e8deb91|8c847a9\u003e: Some commit message - bkraul"
    }
  ]

[bkraul]

I am aware that this could be an issue in the incoming webhook side of things, but the thing is, nothing has changed on that end for weeks, and if I call the webhook directly by URL, it returns a success code

I'm gonna go ahead and test it with the json payload with Insomnia and see what I get..

[lafriks]

Could be that something to do with escaping of < symbols

[lafriks]

It was recently changed to work in both slack and matternost

[bkraul]

OK. I see what the problem is. The incoming webhook is expecting a valid title_link parameter, but gitea is not sending any. It is also not sending a title either. I manually inserted the title_link value into the JSON payload, and the hook call executed successfully.

[bkraul]

I am using RocketChat, which works pretty much in the same way Slack works. As mentioned, this has worked properly for at least a year. Maybe we need a RocketChat setting 😄 ? More info here

[bkraul]

And so, apparently, if there are no attachments object sent, the call from gitea to the hook works fine, because if there are no attachments, there is no requirement for the title_link value. That's probably why it has worked for a while.

This payload works fine

{
  "username": "git",
  "icon_url": "https://my.domain.com/assets/touchicon_180.png",
  "text": "Example message",
  "attachments": null
}

[bkraul]

Sooo...anything that can be done to help this issue? A workaround, a config setting, maybe?

[lunny]

It maybe related with #9422 ?

[jolheiser]

I believe it's caused by #9378, which added TitleLink to the payload.
Perhaps when it is omitted it also works?

Looking at the blame for push actions, the func itself hasn't been touched in a few months. That change was only changing links, so it's unlikely that caused it, and before that change it's been years.
This leads me to believe something changed outside the func, most likely the payload.

My guess is that action needs to set the TitleLink similarly to the other payloads.