Authentication via OpenID cease to function after upgrading to version 1.0.158

[apsonandtesla]

Hosting

• Self
  • Method: docker compose (via Portainer)
  • Budibase Version: 1.0.158

Describe the bug After upgrading from version 1.0.142 to version 1.0.158, authentication via OpenID (using Authentik) ceased to function.

To Reproduce Steps to reproduce the behavior:

1. Set up OpenID authentications
2. Login using OpenID
3. See error (502 Bad Gateway), URL like https://budibase.xxx/api/global/auth/default/oidc/configs/xxxxxxxxxxxx

Expected behavior Able to login using OpenID.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Firefox / Edge
• Version: 100.0.1 / 101.0.1210.47

[Rory-Powell]

Hi @apsonandtesla, could you paste over your logs from bbapps and bbworker during the sign in process

[apsonandtesla]

@Rory-Powell thanks for your reply! Please see the logs attached. And also I have updated the Budibase to 1.0.166 and the problem still exists. bbapps_logs.txt bbworker_logs.txt

[apsonandtesla]

Hi @Rory-Powell do you have any updates on this issue? It's still not working after upgrading to 1.0.196. Anything I can be of help?

[Rory-Powell]

Hi @apsonandtesla, from the logs in the worker service there doesn't appear to be any traffic going to the budibase instance or at least nothing that would explain the error above. The screenshot above doesn't match the expectation I would have for this type of failing request, normally we would see a 500 and some response about what occurred. 502 on this page seems like the redirect is being routed to a reverse proxy with no service behind it, are you using a custom proxy here? Normally we would see nginx but above I can see openresty. Potentially the configured platform url is routing to a different url that the one you would use to visit budibase in the web browser.

[Bergruebe]

Same problem here on version 1.0.214. I'm getting redirected to: https://BUDIBASEURL/api/global/auth/default/oidc/configs/xxxxx and get there a 502 Bad Gateway Error from nginx. I tried different OIDC-Providers, with all I had the same problem.

Here is the log of bbworker:

ERROR [1656853634997] (29 on 26e1e14b62fc):
    req: {
      "id": 49,
      "method": "GET",
      "url": "/api/global/self",
      "headers": {
        "host": "BUDIBASEURL",
        "connection": "close",
        "x-forwarded-for": "xx.xx.xx.xx",
        "x-forwarded-proto": "https",
        "x-real-ip": "xx.xx.xx.xx",
        "accept": "application/json",
        "accept-encoding": "gzip, deflate, br",
        "x-budibase-app-id": "",
        "x-budibase-api-version": "1",
        "user-agent": "xxxxxxx",
        "accept-language": "de-DE,de;q=0.9",
        "referer": "https://BUDIBASEURL/builder/auth/login",
        "cookie": "budibase:returnurl=/builder"
      },
      "remoteAddress": "::ffff:172.26.0.7",
      "remotePort": 33262
    }
    err: {
      "type": "ForbiddenError",
      "message": "Unauthorized - no public worker access",
      "stack":
          ForbiddenError: Unauthorized - no public worker access
              at Object.throw (/app/node_modules/koa/lib/context.js:97:11)
              at /app/dist/api/index.js:109:18
              at dispatch (/app/node_modules/koa-compose/index.js:42:32)
              at /app/node_modules/@koa/router/lib/router.js:368:16
              at dispatch (/app/node_modules/koa-compose/index.js:42:32)
              at /app/node_modules/@budibase/pro/dist/index.js:1:316972
              at Generator.next (<anonymous>)
              at /app/node_modules/@budibase/pro/dist/index.js:1:3797
              at new Promise (<anonymous>)
              at I (/app/node_modules/@budibase/pro/dist/index.js:1:3542)
              at /app/node_modules/@budibase/pro/dist/index.js:1:316768
              at dispatch (/app/node_modules/koa-compose/index.js:42:32)
              at /app/node_modules/@koa/router/lib/router.js:368:16
              at dispatch (/app/node_modules/koa-compose/index.js:42:32)
              at /app/node_modules/@budibase/backend-core/dist/src/middleware/csrf.js:51:20
              at Generator.next (<anonymous>)
      "status": 403,
      "statusCode": 403,
      "expose": true
    }

[Rory-Powell]

Hi @Bergruebe, the 502 is telling us there is no service alive behind the endpoint being hit, otherwise we would see some more details in the log you provided. Do you know which version you were on prior to the upgrade?

It could be worth trying to hit the GET https://BUDIBASEURL/api/global/auth/default/oidc/configs/<id> endpoint manually using a CURL request or tool like postman to check you are getting an alive response, where even a 500 would tell us more. If you're still getting a 502 there is might indicate there is a problem with the nginx configuration on that endpoint

[Bergruebe]

Thank you for your answer @Rory-Powell! With curl from my computer I get the same result:

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.14.2</center>
</body>
</html>

With curl http://localhost:10000/api/global/auth/default/oidc/configs/ on the server I get only Found back.

It looks like the error code is form my nginx reverse proxy:

[error] 28325#28325: *66412 upstream sent too big header while reading response header from upstream, client: XX.XX.XXX.XX, server: BUDIBASEURL, request: "GET /api/global/auth/default/oidc/configs/ID HTTP/2.0", upstream: "http://127.0.0.1:10000/api/global/auth/default/oidc/configs/ID", host: "BUDIBASEURL", referrer: "https:/BUDIBASEURL/builder/auth/login"

My current configuration is out of the Budibase Docs (with added ssl)

server {
    listen 80;
    listen [::]:80;

    server_name BUDIBASEURL;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name BUDIBASEURL;
    include /etc/nginx/ssl.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_http_version 1.1;
        proxy_pass http://localhost:10000;
    }

    client_max_body_size 50m;
}

Do you see, what I did wrong or have any suggestion what I should try?

[Rory-Powell]

@Bergruebe from a search on the error this article might help https://www.cyberciti.biz/faq/nginx-upstream-sent-too-big-header-while-reading-response-header-from-upstream/

The ssl addition here might be causing issues also, does the endpoint respond when you use https rather than http? If so, you might need to update the platform url on the organisation page to also use https. If you're locked out because of the issue you should still be able to use a password to login on your admin user, or if that's not available it can be set in the db by visiting global-db > config_settings and updating the platformUrl field

It might also be worth downgrading to the previous version to see if that fixes the problem, as we can then pinpoint the specific change from the version you were on previously to now to work out the code related issue that triggered this.

[Bergruebe]

Thank you very much @Rory-Powell! The website you mention helped me and solved the problem.

With:

server {
 proxy_busy_buffers_size   512k;
 proxy_buffers   4 512k;
 proxy_buffer_size   256k;
 # rest of nginx config #
}

in my nginx config, everything works fine, as it should.

It might also be worth downgrading to the previous version to see if that fixes the problem, as we can then pinpoint the specific change from the version you were on previously to now to work out the code related issue that triggered this.

This is sadly not possible, because I'm a new Budibase user.