#Set password yourself

1 messages · Page 1 of 1 (latest)

supple hull
#

You might be able to do this by using the recovery feature

#

As the admin when you select "reset password" this will force a recovery for the user which usually involves a email

#

However it requires that you setup your recovery stage in the tenants area where you set default flow

supple hull
#

Hm, and you set this as your default recovery flow in tenants? Are you running the late was the latest version of Authentik?

supple hull
#

Interesting does doing docker-compose logs show any logs relevant to this for errors for instance?

#

Or even notifications as the admin in the user interface section?

supple hull
#

Plus the events section as well

supple hull
#

You don't need to send them, but check for python errors looking through. Most requests will be HTTP based, plus you only need to look at the times that are the same as when you click reset password.

supple hull
#

Is the notification on the top right appearing when you click reset password? What happens when you go to that link? And I'm not sure, I've never used the recovery method yet and I know that reset password won't work without a recovery flow. So its strange to me that it wouldn't use that recovery flow normally.

What does your recovery flow actually look like? Does it require the user enter their name first in the flow before sending the password reset? For instance if they were doing it from the login menu.

Can you send the image flow on here?

supple hull
#

So here's my thoughts..... because you have an identification stage and the user is not identifying themselves, I'm wondering if it's using the flow but not getting anywhere.

If you place a policy on the identification stage and use something like ak_logger to confirm that the flow runs when you click "reset password". You would see ak_logger in docker-compose logs.

If it is running, I'm wondering if the email is not being sent because it does not know who to send it too and/or stuck at the identification stage. Which therefore you might need to see I'd when the identification is ran m, if it's run, what's the context and request being seen sent to it with ak_logger.

Using that information you might be able to create an actual policies that by passes the identification stage and sends the email. This is of course if my presumption about the flow is running and not getting past identification is correct.

supple hull
#

You make an expression policy