OpenID redirect never occurs #1036

New Issue

s87651 · 2021-11-07T01:27:52Z

s87651 commented

2021-11-07 01:27:52 +00:00

I've setup Vikunja API and Client on my server, and it's configured to use my OpenID provider, Authentik.

On previous stable versions, I was actually able to login, before performing any action would subsequently get me kicked out, and logging in again immediately wouldn't work. I could check back then that calls to the API to login would stall out for an entire minute before getting dropped. They did seem to reach the server from the Vikunja logs, but it did not appear to want to give a proper response back to the client.

I'm now on unstable for both the API and Client, and logging in from the OpenID provider gets directed to a page with just the MOTD on it. Attempting to navigate to any of the servicable parts of client would just prompt you to login again. Unfortunately checking logs for the API shows that no request was even possibly made, suggesting that the internal router may just be dropping it, or the URL doesn't exist.

For instance it is redirecting to https://sub.domain.tld/auth/openid/..., but both the the API claims it's never reached, so I assume it's something with the URL.

I've setup Vikunja API and Client on my server, and it's configured to use my OpenID provider, Authentik. On previous stable versions, I was actually able to login, before performing any action would subsequently get me kicked out, and logging in again immediately wouldn't work. I could check back then that calls to the API to login would stall out for an entire minute before getting dropped. They did seem to reach the server from the Vikunja logs, but it did not appear to want to give a proper response back to the client. I'm now on unstable for both the API and Client, and logging in from the OpenID provider gets directed to a page with just the MOTD on it. Attempting to navigate to any of the servicable parts of client would just prompt you to login again. Unfortunately checking logs for the API shows that no request was even possibly made, suggesting that the internal router may just be dropping it, or the URL doesn't exist. For instance it is redirecting to `https://sub.domain.tld/auth/openid/...`, but both the the API claims it's never reached, so I assume it's something with the URL.

konrad added the

kind/bug

label 2021-11-07 14:31:58 +00:00

konrad commented

2021-11-07 14:33:07 +00:00

When you get redirected to the client where it shows just the motd, what does that look like?

Are there any errors in the browser console at that point?

Are you using openid as the only auth provider or do you have Vikunja's local auth still enabled?

When you get redirected to the client where it shows just the motd, what does that look like? Are there any errors in the browser console at that point? Are you using openid as the only auth provider or do you have Vikunja's local auth still enabled?

s87651 commented

2021-11-07 15:11:25 +00:00

When you get redirected to the client where it shows just the motd, what does that look like?

It's just a page with the llama in the bottom right and the MOTD in the middle. Very blank with no additional information. I can screenshot it if you really want. From what I can tell it's literally just this page: https://kolaente.dev/vikunja/frontend/src/branch/main/src/components/home/contentNoAuth.vue

Are there any errors in the browser console at that point?

Nope. It's completely void of any errors, just warnings about fonts.

Are you using openid as the only auth provider or do you have Vikunja's local auth still enabled?

OpenID is enabled as the only auth provider, Local auth is completely disabled.

> When you get redirected to the client where it shows just the motd, what does that look like? It's just a page with the llama in the bottom right and the MOTD in the middle. Very blank with no additional information. I can screenshot it if you really want. From what I can tell it's literally just this page: https://kolaente.dev/vikunja/frontend/src/branch/main/src/components/home/contentNoAuth.vue > Are there any errors in the browser console at that point? Nope. It's completely void of any errors, just warnings about fonts. > Are you using openid as the only auth provider or do you have Vikunja's local auth still enabled? OpenID is enabled as the only auth provider, Local auth is completely disabled.

konrad commented

2021-12-12 12:23:45 +00:00

@s87651 Is this reproducable for you with the latest unstable version (api and frontend)?

What's your Vikunja openid and Authentik config?

I could not reproduce it.

@s87651 Is this reproducable for you with the latest unstable version (api and frontend)? What's your Vikunja openid and Authentik config? I could not reproduce it.

s87651 commented

2021-12-12 18:08:01 +00:00

@konrad Yes, this is still reproducable and still happening with the latest unstable version on both.

My current Vikunja config is here:

auth:
    local:
        enabled: false
    openid:
        enabled: true
        redirecturl: 'https://todo.example.com/auth/openid/'
        providers:
        - name: "extprovider"
          authurl: 'https://authentik.example.com/application/o/vikunja/'
          clientid: "redacted client id"
          clientsecret: "redacted client secret"

Not really sure my Authentik config for the application matters since it's I just use the defaults.

@konrad Yes, this is still reproducable and still happening with the latest unstable version on both. My current Vikunja config is here: ```yaml auth: local: enabled: false openid: enabled: true redirecturl: 'https://todo.example.com/auth/openid/' providers: - name: "extprovider" authurl: 'https://authentik.example.com/application/o/vikunja/' clientid: "redacted client id" clientsecret: "redacted client secret" ``` Not really sure my Authentik config for the application matters since it's I just use the defaults.

konrad commented

2021-12-12 18:53:32 +00:00

What is the exact url in Vikunja where you get redirected to after logging in in Authentik?

s87651 commented

2021-12-13 10:20:44 +00:00

I get redirected to https://todo.example.com/auth/openid/extprovider?code=redacted&state=redacted.

Occassionally (usually after app restart), I'll get logged in, but it won't be too soon after that my requests stop working and logging in will just get me stuck at that URL, or worse, I'll login with nothing working.

I get redirected to `https://todo.example.com/auth/openid/extprovider?code=redacted&state=redacted`. Occassionally (usually after app restart), I'll get logged in, but it won't be too soon after that my requests stop working and logging in will just get me stuck at that URL, or worse, I'll login with nothing working.

konrad commented

2021-12-14 19:46:31 +00:00

Could you open the network tab in the dev tools while trying to authenticate (you may need to enable "persist logs" to avoid requests getting cleared out while redirecting you to new pages), filter for xhr requests and check if there's a POST request to https://todo.example.com/api/v1/auth/openid/extprovider/callback? If there is such a request, what is its response? If not, anything in the browser logs?

btw how are you hosting?

Could you open the network tab in the dev tools while trying to authenticate (you may need to enable "persist logs" to avoid requests getting cleared out while redirecting you to new pages), filter for xhr requests and check if there's a `POST` request to `https://todo.example.com/api/v1/auth/openid/extprovider/callback`? If there is such a request, what is its response? If not, anything in the browser logs? btw how are you hosting?

s87651 commented

2021-12-15 10:55:20 +00:00

If there is such a request, what is its response? If not, anything in the browser logs?

Looks like it fails with Status Code 504.

btw how are you hosting?

DigitalOcean Kubernetes Platform.

> If there is such a request, what is its response? If not, anything in the browser logs? Looks like it fails with Status Code 504. > btw how are you hosting? DigitalOcean Kubernetes Platform.

konrad commented

2021-12-15 12:12:32 +00:00

Looks like it fails with Status Code 504.

What's in the server logs? 504 indicates something is wrong with your proxy. It should have additional logging.

DigitalOcean Kubernetes Platform.

What's your config? (Vikunja, helm, proxy etc)

> Looks like it fails with Status Code 504. What's in the server logs? 504 indicates something is wrong with your proxy. It should have additional logging. > DigitalOcean Kubernetes Platform. What's your config? (Vikunja, helm, proxy etc)

s87651 commented

2021-12-16 14:11:15 +00:00

Looks like it fails with Status Code 504.

What's in the server logs? 504 indicates something is wrong with your proxy. It should have additional logging.

As much as I'd like this to be the case, I do not believe it is. I have multiple applications setup on the cluster, using OpenID Connect with no issue, plus your own APIs on Vikunja are completely reachable and fine (even the callback URL returns if using OPTIONS). There seems to be some failure mode that isn't being handled or displayed in any of the logs, and this seems evident from the proxy logs when calling the request.

(logs from the proxy)

2021/12/16 13:42:43 [error] 175#175: *22956214 upstream timed out (110: Operation timed out) while reading response header from upstream, client: {Client IP Redacted}, server: todo.api.example.com, request: "POST /api/v1/auth/openid/extprovider/callback HTTP/2.0", upstream: "http://{Vikunja Internal Pod IP Redacted}:3456/api/v1/auth/openid/extprovider/callback", host: "todo.api.example.com", referrer: "https://todo.example.com/"

{Client IP Redacted} - - [16/Dec/2021:13:42:43 +0000] "POST /api/v1/auth/openid/extprovider/callback HTTP/2.0" 504 562 "https://todo.example.com/" "{User Agent}" 101 60.000 [{Pod Name}] [] {Vikunja Internal Pod IP Redacted}:3456 0 60.002 504 c604e5b440de1062b324d8225352904f

DigitalOcean Kubernetes Platform.

What's your config? (Vikunja, helm, proxy etc)

I'm not actually using Helm, I've set up the Deployments, Services, and Ingress as so. As for the proxy, I use the default NGINX Ingress Controll er that comes with Kubernetes, and the config for it is rather small.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  allow-snippet-annotations: 'true'
  compute-full-forwarded-for: 'true'
  enable-brotli: 'true'
  proxy-body-size: 756m
  use-forwarded-headers: 'true'
  use-proxy-protocol: 'true'

There is also a Load Balancer to ensure traffic reaches the cluster.

apiVersion: v1
kind: Service
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
annotations:
  service.beta.kubernetes.io/do-loadbalancer-hostname: authentik.example.com
spec:
ports:
  - name: http
    protocol: TCP
    appProtocol: http
    port: 80
    targetPort: http
    nodePort: 31690
  - name: https
    protocol: TCP
    appProtocol: https
    port: 443
    targetPort: https
    nodePort: 32090
type: LoadBalancer
sessionAffinity: None
externalTrafficPolicy: Cluster

> > Looks like it fails with Status Code 504. > > What's in the server logs? 504 indicates something is wrong with your proxy. It should have additional logging. As much as I'd like this to be the case, I do not believe it is. I have multiple applications setup on the cluster, using OpenID Connect with no issue, plus your own APIs on Vikunja are completely reachable and fine (even the callback URL returns if using OPTIONS). There seems to be some failure mode that isn't being handled or displayed in any of the logs, and this seems evident from the proxy logs when calling the request. (logs from the proxy) ``` 2021/12/16 13:42:43 [error] 175#175: *22956214 upstream timed out (110: Operation timed out) while reading response header from upstream, client: {Client IP Redacted}, server: todo.api.example.com, request: "POST /api/v1/auth/openid/extprovider/callback HTTP/2.0", upstream: "http://{Vikunja Internal Pod IP Redacted}:3456/api/v1/auth/openid/extprovider/callback", host: "todo.api.example.com", referrer: "https://todo.example.com/" {Client IP Redacted} - - [16/Dec/2021:13:42:43 +0000] "POST /api/v1/auth/openid/extprovider/callback HTTP/2.0" 504 562 "https://todo.example.com/" "{User Agent}" 101 60.000 [{Pod Name}] [] {Vikunja Internal Pod IP Redacted}:3456 0 60.002 504 c604e5b440de1062b324d8225352904f ``` > > DigitalOcean Kubernetes Platform. > > What's your config? (Vikunja, helm, proxy etc) I'm not actually using Helm, I've set up the Deployments, Services, and Ingress [as so](https://paste.rs/a43.yaml). As for the proxy, I use the default NGINX Ingress Controll er that comes with Kubernetes, and the config for it is rather small. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: ingress-nginx-controller namespace: ingress-nginx data: allow-snippet-annotations: 'true' compute-full-forwarded-for: 'true' enable-brotli: 'true' proxy-body-size: 756m use-forwarded-headers: 'true' use-proxy-protocol: 'true' ``` There is also a Load Balancer to ensure traffic reaches the cluster. ```yaml apiVersion: v1 kind: Service metadata: name: ingress-nginx-controller namespace: ingress-nginx annotations: service.beta.kubernetes.io/do-loadbalancer-hostname: authentik.example.com spec: ports: - name: http protocol: TCP appProtocol: http port: 80 targetPort: http nodePort: 31690 - name: https protocol: TCP appProtocol: https port: 443 targetPort: https nodePort: 32090 type: LoadBalancer sessionAffinity: None externalTrafficPolicy: Cluster ```

konrad commented

2021-12-19 20:04:02 +00:00

Can you verify the Vikunja API container can reach authentik from within the container?

s87651 commented

2021-12-19 21:10:59 +00:00

Can you verify the Vikunja API container can reach authentik from within the container?

From the public URL it's given, yes it can, and does.

Keep in mind that by default, containers usally cannot reach other containers by their hostnames or local container IP. Which is what Vikunja seems to do occassionaly. So if you don't want this behavior to happen, you should always use the public URL and don't do a recursive resolve on it.

> Can you verify the Vikunja API container can reach authentik from within the container? From the public URL it's given, yes it can, and does. Keep in mind that by default, containers usally cannot reach other containers by their hostnames or local container IP. Which is what Vikunja seems to do occassionaly. So if you don't want this behavior to happen, you should always use the public URL and don't do a recursive resolve on it.

konrad commented

2021-12-19 21:25:59 +00:00

Keep in mind that by default, containers usally cannot reach other containers by their hostnames or local container IP. Which is what Vikunja seems to do occassionaly.

Vikunja itself never tries to resolve hosts or urls manually. That's all handled by the rest of the stack.

For the openid callback, it uses the url specified in the config.

Was there anything in the Vikunja API logs?

> Keep in mind that by default, containers usally cannot reach other containers by their hostnames or local container IP. Which is what Vikunja seems to do occassionaly. Vikunja itself never tries to resolve hosts or urls manually. That's all handled by the rest of the stack. For the openid callback, it uses the url specified in the config. Was there anything in the Vikunja API logs?

TheSander562 commented

2022-03-08 12:54:50 +00:00

@konrad Yes, this is still reproducable and still happening with the latest unstable version on both.

My current Vikunja config is here:

auth:
    local:
        enabled: false
    openid:
        enabled: true
        redirecturl: 'https://todo.example.com/auth/openid/'
        providers:
        - name: "extprovider"
          authurl: 'https://authentik.example.com/application/o/vikunja/'
          clientid: "redacted client id"
          clientsecret: "redacted client secret"

Not really sure my Authentik config for the application matters since it's I just use the defaults.

Hello there, i had my problems in the past as well. But i fixed them with this config.
One note i need to say, i am using Authelia as OpenID provider, but maybe my fix can fix yours too.

This is what i configured to make it work:

auth:
  local:
    enabled: false
  openid:
    enabled: true
    redirecturl: https://taak.domain.nl/auth/openid/
    providers:
      - name: vikunja
        authurl: https://auth.domain.nl
        clientid: clientid
        clientsecret: clientsecret

You can see i have authurl: https://auth.domain.nl and you have https://authentik.example.com/application/o/vikunja/

Otherwise what else i see what you have and i dont, is the " " or ' '. I dont use that and my config works, so you could try removing them and check if it works with new url and without ''.

> @konrad Yes, this is still reproducable and still happening with the latest unstable version on both. > > My current Vikunja config is here: > ```yaml > auth: > local: > enabled: false > openid: > enabled: true > redirecturl: 'https://todo.example.com/auth/openid/' > providers: > - name: "extprovider" > authurl: 'https://authentik.example.com/application/o/vikunja/' > clientid: "redacted client id" > clientsecret: "redacted client secret" > ``` > > Not really sure my Authentik config for the application matters since it's I just use the defaults. Hello there, i had my problems in the past as well. But i fixed them with this config. One note i need to say, i am using Authelia as OpenID provider, but maybe my fix can fix yours too. This is what i configured to make it work: ```yaml auth: local: enabled: false openid: enabled: true redirecturl: https://taak.domain.nl/auth/openid/ providers: - name: vikunja authurl: https://auth.domain.nl clientid: clientid clientsecret: clientsecret ``` You can see i have authurl: https://auth.domain.nl and you have https://authentik.example.com/application/o/vikunja/ Otherwise what else i see what you have and i dont, is the " " or ' '. I dont use that and my config works, so you could try removing them and check if it works with new url and without ''.

👍 1

konrad commented

2022-10-01 15:19:29 +00:00

Closing this as I belive it has been solved, please ping if you're still having issues with it.

konrad closed this issue

2022-10-01 15:19:29 +00:00

Sign in to join this conversation.