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.
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?
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.
@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.
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.
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.
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?
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.
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)
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.
> > 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
```
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.
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?
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.
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 ''.
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.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?
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
Nope. It's completely void of any errors, just warnings about fonts.
OpenID is enabled as the only auth provider, Local auth is completely disabled.
@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.
@konrad Yes, this is still reproducable and still happening with the latest unstable version on both.
My current Vikunja config is here:
Not really sure my Authentik config for the application matters since it's I just use the defaults.
What is the exact url in Vikunja where you get redirected to after logging in in Authentik?
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.
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
POSTrequest tohttps://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?
Looks like it fails with Status Code 504.
DigitalOcean Kubernetes Platform.
What's in the server logs? 504 indicates something is wrong with your proxy. It should have additional logging.
What's your config? (Vikunja, helm, proxy etc)
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)
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.
There is also a Load Balancer to ensure traffic reaches the cluster.
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.
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?
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:
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 ''.