Open bepstein111 opened 6 months ago
GoManaged
commented
6 months ago I just had the same issue, the workaround was use Chrome instead of Firefox, and use the HTTPS port instead of HTTP. IE https://172.16.117.253:9443/if/flow/initial-setup/
Which one of those changes sorted it I can't say, but it works now.
FanerYedermann
commented
6 months ago Struggling with a very similar thing atm...
I have a fresh setup where initial setup worked fine, but when I attempt to use the enrollment flow I get the same message. Regular login with the akadmin user works though.
This is the same no matter the browser, incognito or otherwise. I installed using the v2023.10.6 helm chart on Kubernetes, with only an http port (80) exposed on the container. Ingress acts as HTTPS termination.
falkheiland
commented
4 months ago had a similar issue while still had an additional basic auth middleware applied. after removal it worked.
xaviergxf
commented
4 months ago its strange, launching through authentik home works fine, but opening from an incognito window doesn't.
Duoquote
commented
3 months ago Same applies me too, I just installed it to try it out but giving me the same error. Cannot setup.
Duoquote
commented
3 months ago Looks like something is messing up the ui, checked the network and nothing is wrong but the ui doesn't seem to respond how it should, probably because of the extensions I installed.
Tried in mozilla and it works.
LM1LC3N7
commented
3 months ago Same issue here. Fresh installation using last version 2024.2.2 and accessing Authentik redirecting me to the login default page if/flow/default-authentication-flow/?next=%2F and then show an error in both UI and logs.
authentik-server | {"action": "system_exception", "auth_via": "unauthenticated", "client_ip": "172.29.125.27", "context": {"http_request": {"args": {"next": "/"}, "method": "GET", "path": "/api/v3/flows/exe
cutor/default-authentication-flow/", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0"}, "message": "Traceback (most recent call last):\n File \"/ak-root/venv/lib/
python3.12/site-packages/rest_framework/views.py\", line 497, in dispatch\n self.initial(request, *args, **kwargs)\n File \"/ak-root/venv/lib/python3.12/site-packages/sentry_sdk/integrations/django/__init__.
py\", line 312, in sentry_patched_drf_initial\n return old_drf_initial(self, request, *args, **kwargs)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/ak-root/venv/lib/python3.12/site-p
ackages/rest_framework/views.py\", line 414, in initial\n self.perform_authentication(request)\n File \"/ak-root/venv/lib/python3.12/site-packages/rest_framework/views.py\", line 324, in perform_authenticati
on\n request.user\n File \"/ak-root/venv/lib/python3.12/site-packages/rest_framework/request.py\", line 227, in user\n self._authenticate()\n File \"/ak-root/venv/lib/python3.12/site-packages/rest_framew
ork/request.py\", line 380, in _authenticate\n user_auth_tuple = authenticator.authenticate(self)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/authentik/api/authentication.py\", line 99,
in authenticate\n user = bearer_auth(auth)\n ^^^^^^^^^^^^^^^^^\n File \"/authentik/api/authentication.py\", line 37, in bearer_auth\n user = auth_user_lookup(raw_header)\n ^^^^^^^^^^^
^^^^^^^^^^^^^^^^^\n File \"/authentik/api/authentication.py\", line 49, in auth_user_lookup\n auth_credentials = validate_auth(raw_header)\n ^^^^^^^^^^^^^^^^^^^^^^^^^\n File \"/authent
ik/api/authentication.py\", line 29, in validate_auth\n raise AuthenticationFailed(\"Unsupported authentication type\")\nrest_framework.exceptions.AuthenticationFailed: Unsupported authentication type"}, "dom
ain_url": "sub.domain.tld", "event": "Created Event", "host": "sub.domain.tld", "level": "info", "logger": "authentik.events.models", "pid": 84, "request_id": "0beeff0353c04ee78a57dd6bbb6
4a37c", "schema_name": "public", "timestamp": "2024-04-10T10:03:40.324965", "user": {"email": "", "is_anonymous": true, "pk": 1, "username": "AnonymousUser"}}
authentik-server | {"auth_via": "unauthenticated", "domain_url": "sub.domain.tld", "event": "Task published", "host": "sub.domain.tld", "level": "info", "logger": "authentik.root.cel
ery", "pid": 84, "request_id": "0beeff0353c04ee78a57dd6bbb64a37c", "schema_name": "public", "task_id": "1f069fba9c53432b8214437c82aa8a6a", "task_name": "authentik.events.tasks.event_notification_handler", "times
tamp": "2024-04-10T10:03:40.346281"}
thinkhead
commented
3 months ago Same issue here. Error on 2023.10.7 and updating to lastest version 2024.2.2 change nothing. The error happens on every application using oauth or oidc. (like komga,Statping or argocd). The logging work if my users are already login in authentik, but cannot login otherwise. Accessing applications is redirecting me to the login default page if/flow/default-authentication-flow/?next=%2F and then show an error in both UI and logs.
codeagencybe
commented
3 months ago I'm also in the same boat here:
Fresh setup, the initial setup can't even kick off. And once you get the error about request denied, it's persistent and never goes away.
Any update/idea yet why? Been trying a whole week all kinds of ways, but this seems to be a bug. I'm about to give up on Authentik and change to something else.
NorkzYT
commented
3 months ago With the latest Authentik, Docker and Docker Compose version the "Flow does not apply to current user." can be resolved by correcting the providers authentication flow from the incorrect default-source-authentication to default-authentication-flow.
Visual image of this is below:
My docker-compose.yml file:
# Installation: https://hub.docker.com/r/beryju/authentik
version: '3.9'
services:
server:
image: beryju/authentik:2024.2
container_name: authentik
restart: unless-stopped
command: server
user: "root"
environment:
- AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
- AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
- AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
- AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
- AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
- AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
- AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
volumes:
- /opt/appdata/authentik/media:/media
- /opt/appdata/authentik/custom-templates:/templates
- /var/run/docker.sock:/var/run/docker.sock
ports:
- 9815:9000
- 9816:9443
depends_on:
- postgresql-authentik
- redis-authentik
networks:
- proxy
worker:
image: beryju/authentik:2024.2
container_name: authentik_worker
restart: unless-stopped
command: worker
user: "root"
environment:
- AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST}
- AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST}
- AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER}
- AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME}
- AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD}
- AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED}
- AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY}
# `user: root` and the docker socket volume are optional.
# See more for the docker socket integration here:
# https://goauthentik.io/docs/outposts/integrations/docker
# Removing `user: root` also prevents the worker from fixing the permissions
# on the mounted folders, so when removing this make sure the folders have the correct UID/GID
# (1000:1000 by default)
volumes:
- /opt/appdata/authentik/media:/media
- /opt/appdata/authentik/certs:/certs
- /var/run/docker.sock:/var/run/docker.sock
- /opt/appdata/authentik/custom-templates:/templates
depends_on:
- postgresql-authentik
- redis-authentik
networks:
- proxy
postgresql-authentik:
image: postgres:16-alpine3.19
container_name: postgresql-authentik
restart: unless-stopped
healthcheck:
test:
[
'CMD-SHELL',
'pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}'
]
start_period: 20s
interval: 30s
retries: 5
timeout: 5s
environment:
- PUID='1000'
- PGID='1000'
- POSTGRES_USER=${AUTHENTIK_POSTGRESQL__USER}
- POSTGRES_DB=${AUTHENTIK_POSTGRESQL__NAME}
- POSTGRES_PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD:?database password required}
volumes:
- authentik-postgresql-volume:/var/lib/postgresql/data
ports:
- 5432:8080
networks:
- proxy
redis-authentik:
image: redis:alpine3.19
container_name: redis-authentik
restart: unless-stopped
healthcheck:
test: [ 'CMD-SHELL', 'redis-cli ping | grep PONG' ]
start_period: 20s
interval: 30s
retries: 5
timeout: 3s
environment:
- PUID='1000'
- PGID='1000'
volumes:
- authentik-redis-volume:/data
ports:
- 6379:6379
networks:
- proxy
volumes:
authentik-postgresql-volume: {}
authentik-redis-volume: {}
networks:
proxy:
driver: bridge
external: trueAt least this has resolved the issue for myself. I hope this helps everyone else, have a great day!
codeagencybe
commented
3 months ago With the latest Authentik, Docker and Docker Compose version the "
Flow does not apply to current user." can be resolved by correcting the providers authentication flow from the incorrectdefault-source-authenticationtodefault-authentication-flow.Visual image of this is below:
My
docker-compose.ymlfile:# Installation: https://hub.docker.com/r/beryju/authentik version: '3.9' services: server: image: beryju/authentik:2024.2 container_name: authentik restart: unless-stopped command: server user: "root" environment: - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST} - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST} - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER} - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME} - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD} - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED} - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY} volumes: - /opt/appdata/authentik/media:/media - /opt/appdata/authentik/custom-templates:/templates - /var/run/docker.sock:/var/run/docker.sock ports: - 9815:9000 - 9816:9443 depends_on: - postgresql-authentik - redis-authentik networks: - proxy worker: image: beryju/authentik:2024.2 container_name: authentik_worker restart: unless-stopped command: worker user: "root" environment: - AUTHENTIK_REDIS__HOST=${AUTHENTIK_REDIS__HOST} - AUTHENTIK_POSTGRESQL__HOST=${AUTHENTIK_POSTGRESQL__HOST} - AUTHENTIK_POSTGRESQL__USER=${AUTHENTIK_POSTGRESQL__USER} - AUTHENTIK_POSTGRESQL__NAME=${AUTHENTIK_POSTGRESQL__NAME} - AUTHENTIK_POSTGRESQL__PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD} - AUTHENTIK_ERROR_REPORTING__ENABLED=${AUTHENTIK_ERROR_REPORTING__ENABLED} - AUTHENTIK_SECRET_KEY=${AUTHENTIK_SECRET_KEY} # `user: root` and the docker socket volume are optional. # See more for the docker socket integration here: # https://goauthentik.io/docs/outposts/integrations/docker # Removing `user: root` also prevents the worker from fixing the permissions # on the mounted folders, so when removing this make sure the folders have the correct UID/GID # (1000:1000 by default) volumes: - /opt/appdata/authentik/media:/media - /opt/appdata/authentik/certs:/certs - /var/run/docker.sock:/var/run/docker.sock - /opt/appdata/authentik/custom-templates:/templates depends_on: - postgresql-authentik - redis-authentik networks: - proxy postgresql-authentik: image: postgres:16-alpine3.19 container_name: postgresql-authentik restart: unless-stopped healthcheck: test: [ 'CMD-SHELL', 'pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}' ] start_period: 20s interval: 30s retries: 5 timeout: 5s environment: - PUID='1000' - PGID='1000' - POSTGRES_USER=${AUTHENTIK_POSTGRESQL__USER} - POSTGRES_DB=${AUTHENTIK_POSTGRESQL__NAME} - POSTGRES_PASSWORD=${AUTHENTIK_POSTGRESQL__PASSWORD:?database password required} volumes: - authentik-postgresql-volume:/var/lib/postgresql/data ports: - 5432:8080 networks: - proxy redis-authentik: image: redis:alpine3.19 container_name: redis-authentik restart: unless-stopped healthcheck: test: [ 'CMD-SHELL', 'redis-cli ping | grep PONG' ] start_period: 20s interval: 30s retries: 5 timeout: 3s environment: - PUID='1000' - PGID='1000' volumes: - authentik-redis-volume:/data ports: - 6379:6379 networks: - proxy volumes: authentik-postgresql-volume: {} authentik-redis-volume: {} networks: proxy: driver: bridge external: trueAt least this has resolved the issue for myself. I hope this helps everyone else, have a great day!
this is not the same issue we are reporting. You already got "in" Authentik. We can't even do the initial admin account create immediately after Authentik is spin up. It locks completely from the first minute. And once it's locked, it remains like this. The only way to continue is docker compose down, remove volume and docker compose up again to have another try and to have the same error over and over.
It's happening since the last 2 or 3 released afaik.
NorkzYT
commented
3 months ago @codeagencybe Ah, understood. That is a strange issue.
balderekjk
commented
3 months ago I was also in the same boat yesterday. I found a temporary workaround, so it is possible to log in as admin without completing the initial-setup step due to this bug(?).
The solution below is sourced verbatim from their Troubleshooting: Login page.
To create the key, run the following command:
docker compose run --rm server create_recovery_key 10 akadmin
For Kubernetes, run
kubectl exec -it deployment/authentik-worker -c authentik -- ak create_recovery_key 10 akadmin
or, for CLI, run
ak create_recovery_key 10 akadmin
This will output a link, that can be used to instantly gain access to authentik as the user specified above. The link is valid for amount of years specified above, in this case, 10 years.
When you are inside click the following:
Admin Interface (navbar) > Directory (sidebar) > Users (option in dropdown) > akadmin (link) > User Info (left-side section) > Set Password (button)
When your password is set, you should be able to log in as akadmin.
codeagencybe
commented
3 months ago I managed to get my issue solved by changing the LISTEN HTTP flags as following:
AUTHENTIK_LISTEN__HTTP=authentik-server:8000
AUTHENTIK_LISTEN__HTTPS=authentik-server:8443
I think the problem was coming from a port conflict with Portainer who occupies ports 8000, 9000 and 9443 by default. I already changed the ports for Authentik to 8000 and 8443 but for some reason I found in the logs parts of "output" trying to do something on port 9000 which is obviously going to Portainer container and failing.
After I set these 2 extra params, matching the same ports on COMPOSE_PORT, the problem was solved.
Also, updating to image version 2024.4.0 fixed some other issues.
bepstein111
commented
2 months ago At the end of the day, I ended up getting around this by using the AUTHENTIKBOOTSTRAP variables to register a user during image creation. That worked, but I ran into so many other issues with getting authentication actually working that I just gave up and left it alone for a while. Trying again with all of this this weekend...
ihaddy
commented
2 months ago fresh install of authentik and can confirm this is still an issue where a fresh install doesn't let you setup a user and then permanently locks you out unless you drop the entire DB or volume the db is on to try again and repeat this loop. Using the standard instructions of just making the compose, running it, and attempting the initial flow at /if/flow/initial-setup/ on either https or http on either firefox or chrome.
This is a showstopper bug which really puts me off to adopting this in my enterprise if there's a gamebreaking issue with the most vanilla setup in my homelab (that's been open since january it looks like?), as a dev / devops engineer I know resources are limited and there's always something more pressing in the backlog but i literally can't sell my org on adopting this if the default docker-compose instructions simply don't work to demo it!
quincarter
commented
2 months ago So if you are behind a reverse proxy much like traefik and are setting up your subdomains like most videos tell you, authentik.example.com then you need to check a couple of things. I just got this working with the latest pin with traefik after days of troubleshooting the same exact error.
I run portainer in my setup, so i had to setup these env variables (as listed above so thanks @codeagencybe )
AUTHENTIK_LISTEN__HTTP=authentik-server:8000
AUTHENTIK_LISTEN__HTTPS=authentik-server:8443If you are setting an explicit AUTHENTIK_COOKIE_DOMAIN env variable, try without it. see docs.
Here's my authentik-server config
authentik-server:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-latest}
container_name: authentik-server
restart: unless-stopped
command: server
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
AUTHENTIK_HOST_BROWSER: https://authentik.${PROJECT_HOSTNAME}
volumes:
- ${DEFAULT_CONTAINER_DATA_LOCATION}/Authentik/media:/media
- ${DEFAULT_CONTAINER_DATA_LOCATION}/Authentik/custom-templates:/templates
networks:
- zauthentik # i had to do zauthentik because i had network priority issues so this makes it last for my auth backend
- homelab
env_file:
- ../.env
ports:
- 8000:8000
labels:
- "traefik.enable=true"
- "traefik.http.routers.authentik-server.rule=Host(`authentik.${PROJECT_HOSTNAME}`)"
- "traefik.http.routers.authentik-server.entrypoints=https" # or i have seen a lot of people call this websecure
- "traefik.http.routers.authentik-server.tls=true"
- "traefik.http.routers.authentik-server.tls.certresolver=${TRAEFIK_TLS_CERTRESOLVER}"
- "traefik.http.routers.authentik-server.service=authentik-svc"
- "traefik.http.services.authentik-svc.loadBalancer.server.port=8000"
depends_on:
- postgresql
- redis
- traefik
profiles:
- all
- authentik
- traefikand then here's my dynamic configuration:
http:
middlewares:
# https://github.com/goauthentik/authentik/issues/2366
middlewares-authentik:
forwardAuth:
address: http://authentik-server:8000/outpost.goauthentik.io/auth/traefik # authentik-server matches the name of the container or service i think
trustForwardHeader: true
authResponseHeaders:
- X-authentik-username
- X-authentik-groups
- X-authentik-email
- X-authentik-name
- X-authentik-uid
- X-authentik-jwt
- X-authentik-meta-jwks
- X-authentik-meta-outpost
- X-authentik-meta-provider
- X-authentik-meta-app
- X-authentik-meta-versionDoing all that finally allowed me to get in. Ultimately i think the COOKIE_DOMAIN thing is what did it for me. I figured it out because i could get in fine from localhost:8000 but when i tried to go reverse proxy it was just failing. So i knew something was up with the way the hostname was getting parsed or something.
When i originally checked my request headers, i saw that the domain the access token was setting was localhost and wasn't my FQDN for my authentik instance in my homelab.
ihaddy
commented
2 months ago I was also in the same boat yesterday. I found a temporary workaround, so it is possible to log in as admin without completing the initial-setup step due to this bug(?).
The solution below is sourced verbatim from their Troubleshooting: Login page.
To create the key, run the following command:
docker compose run --rm server create_recovery_key 10 akadminFor Kubernetes, run
kubectl exec -it deployment/authentik-worker -c authentik -- ak create_recovery_key 10 akadminor, for CLI, run
ak create_recovery_key 10 akadminThis will output a link, that can be used to instantly gain access to authentik as the user specified above. The link is valid for amount of years specified above, in this case, 10 years.
When you are inside click the following:
Admin Interface (navbar) > Directory (sidebar) > Users (option in dropdown) > akadmin (link) > User Info (left-side section) > Set Password (button)
When your password is set, you should be able to log in as akadmin.
this doesn't seem to work (anymore?). I get the URL generated correctly, visit it, and it looks like it loads the app for a split second before the frontend realizes the user isn't authed / created properly / some other error, and it kicks me back out to this page
the URL then changes to /if/flow/default-authentication-flow/?next=%2Fif%2Fuser%2F
to re-iterate, this is on a fresh install where i can't get completing visiting the URL if/flows/initial-setup to work. I've tried after i lock myself out by entering any info or even wrong info if/flows/initial-setup or before i even visit if/flows/initial-setup, the behavior is the same.
quincarter
commented
2 months ago If you're in docker, make sure you don't have any residual volumes or DB data and try incognito mode too. Authentik has some stuff that may be cached.
ihaddy
commented
2 months ago Yeah i'm just straight up deleting the docker volume everytime that has the DB and watching it rerun all the migrations etc.
Wasn't trying with incognito before, forgot they'd store cookies, but am trying it now to no avail just the same.
Thanks for the help.
of note, i'm not running any reverse proxy in front of it, and i do see people talking about setting these in their comments above (i've changed the values to match my compose)
AUTHENTIK_LISTEN__HTTP=server:9003
AUTHENTIK_LISTEN__HTTPS=server:9445but when i add these in, my app is actually just not reachable at all.
using this compose that i grabbed from the official instructions, the main thing i changed was just the ports basically.
---
version: "3.4"
services:
postgresql:
image: docker.io/library/postgres:12-alpine
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
start_period: 20s
interval: 30s
retries: 5
timeout: 5s
volumes:
- database:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: ${PG_PASS:?database password required}
POSTGRES_USER: ${PG_USER:-authentik}
POSTGRES_DB: ${PG_DB:-authentik}
env_file:
- .env
redis:
image: docker.io/library/redis:alpine
command: --save 60 1 --loglevel warning
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "redis-cli ping | grep PONG"]
start_period: 20s
interval: 30s
retries: 5
timeout: 3s
volumes:
- redis:/data
server:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.4.2}
restart: unless-stopped
command: server
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
volumes:
- ./media:/media
- ./custom-templates:/templates
env_file:
- .env
ports:
- "${COMPOSE_PORT_HTTP:-9003}:9000"
- "${COMPOSE_PORT_HTTPS:-9445}:9443"
depends_on:
- postgresql
- redis
worker:
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.4.2}
restart: unless-stopped
command: worker
environment:
AUTHENTIK_REDIS__HOST: redis
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
# `user: root` and the docker socket volume are optional.
# See more for the docker socket integration here:
# https://goauthentik.io/docs/outposts/integrations/docker
# Removing `user: root` also prevents the worker from fixing the permissions
# on the mounted folders, so when removing this make sure the folders have the correct UID/GID
# (1000:1000 by default)
user: root
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- ./media:/media
- ./certs:/certs
- ./custom-templates:/templates
env_file:
- .env
depends_on:
- postgresql
- redis
volumes:
database:
driver: local
redis:
driver: localweird that when i add those two variables to my env file, i'm not able to connect to the app's frontend at all, so i've just removed those and i don't specify a compose value either. the app seems to boot successfully from the logs
quincarter
commented
2 months ago Maybe give this .env a look. Compare it to yours maybe. That's what I use.
quincarter
commented
2 months ago Also possibly give their docs a look.
https://homemediadocker.github.io/Home-Media-Docker/docs/authentik-sso
quincarter
commented
2 months ago Note that this container uses an internal network called homelab and zauthentik. This is because the networks for docker get appended in alphabetical order based on priority by default (pretty sure).
I noticed yours didn't have a network defined so it should just use the default docker network
quincarter
commented
2 months ago Also this one has the ports commented out too for Authentik - this is because it is behind a reverse proxy.
abediali
commented
2 months ago AUTHENTIK_LISTEN__HTTP=server:9003 AUTHENTIK_LISTEN__HTTPS=server:9445
but when i add these in, my app is actually just not reachable at all.
Try using the ports it listens to internally, 9000 & 9443. Had same issue then I realized the variables apple internally not external to docker where there's a port forward.
freebs65
commented
2 months ago I'm having the same issue... i can get in via recovery link but no one else can log in.
I made no changes (that I know of) and am running the latest version 2024..4.2 .. I woke up the next day and couldn't log in.
Bashing my head trying things... i'm using nginx proxy manger in front of authentik.
Everything was just fine and boom... this happened.
and this is in my .env file
COMPOSE_PORT_HTTP=8080 COMPOSE_PORT_HTTPS=4443
ATHENTIK_TAG=2024.4.2
Resolved my issue... so stupid.. but I still don't know how it happened..
radhoo2k10
commented
1 month ago This worked for me: Removed/deleted the docker and the volumes. The secret keys that I generated with Bitwarden contained special characters as !@#%^&* It seems like it dosn't like that. So I created new keys without those characters. Redeployed the docker and it worked. Created an admin user and are now in the program.
ihaddy
commented
1 month ago This worked for me: Removed/deleted the docker and the volumes. The secret keys that I generated with Bitwarden contained special characters as !@#%^&* It seems like it dosn't like that. So I created new keys without those characters. Redeployed the docker and it worked. Created an admin user and are now in the program.
that seems to have been the issue for me, i had a "+" in my secretkey for authentik and it caused all this mayhem. Removing all special characters and i can happy path install it from scratch per the documentation!
theWarFlower
commented
1 month ago This worked for me: Removed/deleted the docker and the volumes. The secret keys that I generated with Bitwarden contained special characters as !@#%^&* It seems like it dosn't like that. So I created new keys without those characters. Redeployed the docker and it worked. Created an admin user and are now in the program.
that seems to have been the issue for me, i had a "+" in my secretkey for authentik and it caused all this mayhem. Removing all special characters and i can happy path install it from scratch per the documentation!
Thank you this was the whole problem for me. Default installation instructions allow for illegal characters in the key. Removing '+' and redeploying fixed it.
veenified
commented
4 days ago Here's a revised line for the Installation instructions:
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -dc 'a-zA-Z0-9' | tr -d '\n')" >> .env
Describe your question/ Simply set up Authentik in portainer with a stack.
Relevant infos Debian 12, Portainer BE 2.19.4, Docker-ce 5:24.0.7, Docker Compose 2.21.0, Authentik 2023.10.6
Screenshots
Logs
Version and Deployment (please complete the following information):
Additional context After seemingly sucessfully starting Authentik up, I go to if/flows/initial-setup, I enter in my email and password that I want to use, and every single time, I get this message showing up. What am I doing wrong??? What does it mean flow isn't applicable to current user? There are no users! I'm attempting to create the first one!!