[Bug]: Deploy API is not working

[AxeemHaider]

Description

Deploy API is not working getting always error

{
  "message": "You are not allowed to perform this action."
}

This is not the token problem I created token with full access and I'm able to access other api restricted endpoints with this same token.

I tried both GET and POST requests.

Minimal Reproduction (if possible, example repository)

1. Create API token
2. Go to Deploy API
3. send request (you get error)

Exception or Error

No response

Version

v4.0.0-beta.319

Cloud?

• [ ] Yes
• [X] No

[andrasbacsai]

I cannot reproduce it. Only the read-only tokens are not able to deploy.

Can you please show me an example request (truncate your api token)?

[AxeemHaider]

Here are the steps to reproduce this error.

1. Create API Token with read-only and view sensitive data permissions.

2. Copy deploy webhook url from Configuration

3. Send GET or POST API request to deploy webhook url using same API Token.

Here is sended request detail (url and ip address are replaced.)

curl -v --request GET 'https://coolify.example.com/api/v1/deploy?uuid=vskswkw&force=false' --header 'Authorization: Bearer 6|JIREimrfam9zsxaoWuIBPTh7cHrjBZYRKn4L1vuH5463d8e8'
Note: Unnecessary use of -X or --request, GET is already inferred.

• Trying 123.456.789.432:443...
• Connected to coolify.example.com (123.456.789.432) port 443
• ALPN: curl offers h2,http/1.1
• (304) (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/cert.pem
• CApath: none
• (304) (IN), TLS handshake, Server hello (2):
• (304) (IN), TLS handshake, Unknown (8):
• (304) (IN), TLS handshake, Certificate (11):
• (304) (IN), TLS handshake, CERT verify (15):
• (304) (IN), TLS handshake, Finished (20):
• (304) (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256
• ALPN: server accepted h2
• Server certificate:
• subject: CN=coolify.example.com
• start date: Aug 7 04:46:33 2024 GMT
• expire date: Nov 5 04:46:32 2024 GMT
• subjectAltName: host "coolify.example.com" matched cert's "coolify.example.com"
• issuer: C=US; O=Let's Encrypt; CN=R10
• SSL certificate verify ok.
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://coolify.example.com/api/v1/deploy?uuid=vskswkw&force=false
• [HTTP/2] [1] [:method: GET]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: coolify.example.com]
• [HTTP/2] [1] [:path: /api/v1/deploy?uuid=vskswkw&force=false]
• [HTTP/2] [1] [user-agent: curl/8.4.0]
• [HTTP/2] [1] [accept: /]
• [HTTP/2] [1] [authorization: Bearer 6|JIREimrfam9zsxaoWuIBPTh7cHrjBZYRKn4L1vuH5463d8e8]

  GET /api/v1/deploy?uuid=vskswkw&force=false HTTP/2 Host: coolify.example.com User-Agent: curl/8.4.0 Accept: / Authorization: Bearer 6|JIREimrfam9zsxaoWuIBPTh7cHrjBZYRKn4L1vuH5463d8e8

< HTTP/2 403 < access-control-allow-origin: * < cache-control: no-cache, private < content-type: application/json < date: Thu, 08 Aug 2024 03:22:44 GMT < referrer-policy: no-referrer-when-downgrade < server: nginx < strict-transport-security: max-age=31536000; includeSubDomains < vary: Accept-Encoding < x-content-type-options: nosniff < x-frame-options: SAMEORIGIN < x-ratelimit-limit: 200 < x-ratelimit-remaining: 198 <

• Connection #0 to host coolify.example.com left intact {"message":"You are not allowed to perform this action."}%

[Vahor]

The ui might not be perfect here, you have to uncheck both "read-only" and "view sensitive data" to have a "admin token".

[erehwonmi]

I encountered this today, @Vahor thanks. It took me almost an hour to resolve this, haha, UI/UX could be improved. I didn't know that unchecking all the boxes was all it took to fix it. Another improvement would be to pass a "version" to the deploy API so that we can tag the commit version.

[sneko]

@andrasbacsai from a security perspective I think deployment hooks should not require admin role, because they are most of the time registered into CI/CD pipelines and it's a bit at risk if it's able to manage your whole infrastructure.

[michaldudek]

To add to that, deployment hooks should not require auth at all. This is how Vercel does it - but there's a token in the URL.

Many services will not allow to add any additional headers to their webhooks. E.g. if I'm using a headless CMS and want to redeploy after content changes, I should simply be able to give that CMS a webhook URL to call and that's it.

And whatever token is included, it should only be allowed to redeploy the deployment and not access any other resources.