github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-07 03:58:09 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

sticky openid login / Authentik OpenID misconfiguration #220

New Issue
Closed
opened 2025-11-01 20:51:15 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2025-11-01 20:51:15 -05:00
Owner
Copy Link

Originally created by @mrpops2ko on GitHub (Apr 25, 2024).

Description

hi so i have found what i think is a bug and also the rest of the information is me trying to debug wrongly configured routing on my own part, so please ignore it but its good to keep it around for anybody who is silly enough to have forward auth configured and were declaring authentik as a traefik middleware like - "traefik.http.routers.vikunja.middlewares=authentik@file" im sure others will find this from google in time

now onto the bug (or 2 rather, one is in the documentation of openid, you forgot a trailing slash in the authurl part)

and the other is in relation to the logic of openid

what i've observed is this, and i've reproduced it a few times now to check too

start order is important for the 'log in with authentik' button to appear

if i start vikunja without authentik / traefik then the button disappears and never will be visible

if i start authentik / traefik and then start vikunja then the button appears

a possible solution to this is some retry mechanism

==========================================================================

i'm following your documentation on how to implement openid auth and it seems im doing something wrong but i've gone over the config 15 times now and i'm reasonably sure i've followed it exactly and it still doesn't work.

I use traefik and authentik. To start I verified that I could reach vikunja through traefik without an middleware auth.

I then added authentik middleware, which i have verified works on other applications.
- "traefik.http.routers.vikunja.middlewares=authentik@file"

I then added the config.yml and noticed it wouldn't load, i resolved this issue by adding VIKUNJA_SERVICE_ROOTPATH: /app/vikunja/files so that it would then work and pick up the config, the logs verify it does and if i ssh and cat the file it confirms to what is bindmounted

2024-04-25T14:55:15.025605133+01:00: INFO ▶ config/InitConfig 001 Using config file: /app/vikunja/files/config.yml

What may be the issue could possibly be my traefik label for authentik, i have it set up to work with the forward auth proxy but this rule might need to be expanded further to support openid and requests that vikunja might be making to authentik via that

authentik resides at auth.domain.com
vikunja resides at vikunja.domain.com

currently this is the label for authentik
- "traefik.http.routers.authentik.rule=Host(`auth.domain.com`) || HostRegexp(`{subdomain:[a-z0-9]+}.domain.com``) && PathPrefix(`/outpost.goauthentik.io/`)"

i've followed this guide https://vikunja.io/docs/openid-example-configurations/ and followed the config exactly and it doesn't work.

I started to play around with various URLs to see if it was that, and noticed that authurl: "https://authentik.mydomain.com/application/o/vikunja" this didn't work but adding a trailing slash to it did

this didn't resolve my problem but at least it brought me to an authentik page which states information like

  "issuer": "https://auth.domain.com/application/o/vikunja/",
  "authorization_endpoint": "https://auth.domain.com/application/o/authorize/",
  "token_endpoint": "https://auth.domain.com/application/o/token/",
  "userinfo_endpoint": "https://auth.domain.com/application/o/userinfo/",
  "end_session_endpoint": "https://auth.domain.com/application/o/vikunja/end-session/",
  "introspection_endpoint": "https://auth.domain.com/application/o/introspect/",
  "revocation_endpoint": "https://auth.domain.com/application/o/revoke/",
  "device_authorization_endpoint": "https://auth.domain.com/application/o/device/",

so i suspect that at least needs updating in the docs, but i'm still without success in able to access vikunja with authentik and i'm not sure what else to try now

additional things i've tried:
removing all quotation marks, i attempted to compare and contrast the examples and in the first few you offer yaml without quotations and the authentik one you didn't - this didn't resolve the issue (and i dont think wrapping in quotation marks is an issue)

Finally I figured it out, what I was wrongly not realising is that OpenID and forward auth proxying are 2 completely mutually exclusive things - i can't add an authentik forward auth that sits in front of vikunja (or well you can but that is not openid)

openid act as a login provider, and the front facing part will still be vikunja the user just needs to click the log in with authentik button and it will work.

Vikunja Version

latest

Browser and version

chrome

Can you reproduce the bug on the Vikunja demo site?

Please select

Screenshots

No response

Originally created by @mrpops2ko on GitHub (Apr 25, 2024). ### Description hi so i have found what i think is a bug and also the rest of the information is me trying to debug wrongly configured routing on my own part, so please ignore it but its good to keep it around for anybody who is silly enough to have forward auth configured and were declaring authentik as a traefik middleware like ``` - "traefik.http.routers.vikunja.middlewares=authentik@file"``` im sure others will find this from google in time now onto the bug (or 2 rather, one is in the documentation of openid, you forgot a trailing slash in the authurl part) and the other is in relation to the logic of openid what i've observed is this, and i've reproduced it a few times now to check too start order is important for the 'log in with authentik' button to appear if i start vikunja without authentik / traefik then the button disappears and never will be visible if i start authentik / traefik and then start vikunja then the button appears a possible solution to this is some retry mechanism ========================================================================== i'm following your documentation on how to implement openid auth and it seems im doing something wrong but i've gone over the config 15 times now and i'm reasonably sure i've followed it exactly and it still doesn't work. I use traefik and authentik. To start I verified that I could reach vikunja through traefik without an middleware auth. I then added authentik middleware, which i have verified works on other applications. ``` - "traefik.http.routers.vikunja.middlewares=authentik@file"``` I then added the config.yml and noticed it wouldn't load, i resolved this issue by adding ``` VIKUNJA_SERVICE_ROOTPATH: /app/vikunja/files``` so that it would then work and pick up the config, the logs verify it does and if i ssh and cat the file it confirms to what is bindmounted ```2024-04-25T14:55:15.025605133+01:00: INFO ▶ config/InitConfig 001 Using config file: /app/vikunja/files/config.yml``` What may be the issue could possibly be my traefik label for authentik, i have it set up to work with the forward auth proxy but this rule might need to be expanded further to support openid and requests that vikunja might be making to authentik via that authentik resides at auth.domain.com vikunja resides at vikunja.domain.com currently this is the label for authentik ``` - "traefik.http.routers.authentik.rule=Host(`auth.domain.com`) || HostRegexp(`{subdomain:[a-z0-9]+}.domain.com``) && PathPrefix(`/outpost.goauthentik.io/`)"``` i've followed this guide https://vikunja.io/docs/openid-example-configurations/ and followed the config exactly and it doesn't work. I started to play around with various URLs to see if it was that, and noticed that ``` authurl: "https://authentik.mydomain.com/application/o/vikunja"``` this didn't work but adding a trailing slash to it did this didn't resolve my problem but at least it brought me to an authentik page which states information like ```{ "issuer": "https://auth.domain.com/application/o/vikunja/", "authorization_endpoint": "https://auth.domain.com/application/o/authorize/", "token_endpoint": "https://auth.domain.com/application/o/token/", "userinfo_endpoint": "https://auth.domain.com/application/o/userinfo/", "end_session_endpoint": "https://auth.domain.com/application/o/vikunja/end-session/", "introspection_endpoint": "https://auth.domain.com/application/o/introspect/", "revocation_endpoint": "https://auth.domain.com/application/o/revoke/", "device_authorization_endpoint": "https://auth.domain.com/application/o/device/", ``` so i suspect that at least needs updating in the docs, but i'm still without success in able to access vikunja with authentik and i'm not sure what else to try now additional things i've tried: removing all quotation marks, i attempted to compare and contrast the examples and in the first few you offer yaml without quotations and the authentik one you didn't - this didn't resolve the issue (and i dont think wrapping in quotation marks is an issue) Finally I figured it out, what I was wrongly not realising is that OpenID and forward auth proxying are 2 completely mutually exclusive things - i can't add an authentik forward auth that sits in front of vikunja (or well you can but that is not openid) openid act as a login provider, and the front facing part will still be vikunja the user just needs to click the log in with authentik button and it will work. ### Vikunja Version latest ### Browser and version chrome ### Can you reproduce the bug on the Vikunja demo site? Please select ### Screenshots _No response_
GiteaMirror commented 2025-11-01 20:51:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Apr 26, 2024):

what i've observed is this, and i've reproduced it a few times now to check too

start order is important for the 'log in with authentik' button to appear

if i start vikunja without authentik / traefik then the button disappears and never will be visible

if i start authentik / traefik and then start vikunja then the button appears

This is by design. Vikunja will try to reach the auth provider when the first request to the /api/v1/info endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work.

Where exactly is the slash missing in the docs? The actual url used is inferred from the .well-known response from the provider.

@kolaente commented on GitHub (Apr 26, 2024): > what i've observed is this, and i've reproduced it a few times now to check too > > start order is important for the 'log in with authentik' button to appear > > if i start vikunja without authentik / traefik then the button disappears and never will be visible > > if i start authentik / traefik and then start vikunja then the button appears This is by design. Vikunja will try to reach the auth provider when the first request to the `/api/v1/info` endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work. Where exactly is the slash missing in the docs? The actual url used is inferred from the `.well-known` response from the provider.
GiteaMirror commented 2025-11-01 20:51:16 -05:00
Author
Owner
Copy Link

@mrpops2ko commented on GitHub (Apr 26, 2024):

what i've observed is this, and i've reproduced it a few times now to check too
start order is important for the 'log in with authentik' button to appear
if i start vikunja without authentik / traefik then the button disappears and never will be visible
if i start authentik / traefik and then start vikunja then the button appears

This is by design. Vikunja will try to reach the auth provider when the first request to the /api/v1/info endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work.

Where exactly is the slash missing in the docs? The actual url used is inferred from the .well-known response from the provider.

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

https://gyazo.com/52bee35cd51e586e771a3988b422a648.png trailing slash here

@mrpops2ko commented on GitHub (Apr 26, 2024): > > what i've observed is this, and i've reproduced it a few times now to check too > > start order is important for the 'log in with authentik' button to appear > > if i start vikunja without authentik / traefik then the button disappears and never will be visible > > if i start authentik / traefik and then start vikunja then the button appears > > This is by design. Vikunja will try to reach the auth provider when the first request to the `/api/v1/info` endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work. > > Where exactly is the slash missing in the docs? The actual url used is inferred from the `.well-known` response from the provider. what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO https://gyazo.com/52bee35cd51e586e771a3988b422a648.png trailing slash here
GiteaMirror commented 2025-11-01 20:51:16 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (May 3, 2024):

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly.

If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it.

@kolaente commented on GitHub (May 3, 2024): > what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly. If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it.
GiteaMirror commented 2025-11-01 20:51:16 -05:00
Author
Owner
Copy Link

@mrpops2ko commented on GitHub (May 4, 2024):

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly.

If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it.

alright thank you, well i can only hope that you will reconsider this design decision because on some levels it makes no sense.

if we were to add up the cumulative cost, across every single vikunja user hitting some endpoint that was down, once every say 30 seconds i'm sure the cumulative cost across the span of a year is less than $5

the amount of wasted cpu cycles, extra 'load' and all the rest is so virtually low that if we were to graph it out it'd be so statistically insignificant that it'd be questionable if it was real

we are literally talking about loading what is likely a traefik 404 page if its a self hosted auth is down and repeating that every 30 seconds or whatever arbitary retry mechanism value, which im sure nobody is losing sleep over or could ever quantify into meaningful monetary loss or wasted performance

@mrpops2ko commented on GitHub (May 4, 2024): > > what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO > > It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly. > > If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it. alright thank you, well i can only hope that you will reconsider this design decision because on some levels it makes no sense. if we were to add up the cumulative cost, across every single vikunja user hitting some endpoint that was down, once every say 30 seconds i'm sure the cumulative cost across the span of a year is less than $5 the amount of wasted cpu cycles, extra 'load' and all the rest is so virtually low that if we were to graph it out it'd be so statistically insignificant that it'd be questionable if it was real we are literally talking about loading what is likely a traefik 404 page if its a self hosted auth is down and repeating that every 30 seconds or whatever arbitary retry mechanism value, which im sure nobody is losing sleep over or could ever quantify into meaningful monetary loss or wasted performance
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#220
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?