We have some accounts that have seemingly been the...
# ory-network
a
We have some accounts that have seemingly been the victim of a credentials stuffing attack. How can we invalidate their current password and enforce creating a new one next time they login? We have tried deleting the credentials but face the "You cannot remove first factor credentials." error. Sending all of them an email to reset is not really practical.
okay, seems like this is not supported out of the box but is just about implementable using hooks.
Are there any complete schemas around what to expect in the CTX when working with hooks and actions please?
And anyway to get a nice message back to the ui rather than this?
Copy code
message
: 
"jsonnetsecure: ERROR: RUNTIME ERROR: forceResetPassword\n\t<https://storage.googleapis.com/bac-gcs-production/5b9ea6ed83ad4ae4f008900cc879253d3f7243e0279ff8b76428ae9df53ea605f616598c090af535093b7aba3df9efeb758f06f3bb7c4d98d565eb624406dcab.jsonnet:6:7-33>\tfunction <anonymous>\n\tTop-level function call\t\n"
g
the error seems like the jsonnet was not properly defined. there is a doc on how to write a jsonnet I have a very generic template i made use of. but you can adapt it to your use. Here is a sample
a
Hi @gray-library-49237 - thanks for this.... yes, I've seen the samples but would really like a complete schema on what to expect in each and every hook. For example,
ctx.identity
does not exist in any before hooks (at least as far as we can tell) As for the errors, not that I am returning an error directly from the jsonnet on purpose in some cases where there's no need to make an actual network call to a webhook. It's these cases where we get the quite ugly error such as above. Here's an example from our profile change hook that prevents users changing their email address.
Copy code
function(ctx)
if std.objectHas(ctx.identity, "traits") && std.objectHas(ctx.identity.traits, "email") then
  error "emailChangeForbidden"
else
  error "cancel"
For example, we are trying to reset some data on the user after they have reset their password. But we can't find anything in the documentation which describes what to expect in the
ctx
.
e.g. we get a ctx like this for a password reset but it's not clear how to know if this is specifically for password reset or not:
Copy code
"flow": {
	"expires_at": "2024-10-13T15:08:55.025083Z",
	"active": "code",
	"return_to": "/auth/new-password",
	"id": "af36ed50-d1a6-4f80-9f7f-d59e7355ec05",
	"state": "passed_challenge",
	"type": "browser",
	"issued_at": "2024-10-13T14:38:55.025083Z",
	"request_url": "<https://foobar.projects.oryapis.com/self-service/recovery/browser?return_to=%2Fauth>"
}
(except for our own
return_to
url of course but that doesnt' seem the most reliable.
actually, looks like we're hooked in to the wrong action anyway. Since recovery doesn't actually mean a successful password change.
g
> For example,
ctx.identity
does not exist in any before hooks (at least as far as we can tell) yes this is true. But sadly i do not have a complete sample of each steps. > e.g. we get a ctx like this for a password reset but it's not clear how to know if this is specifically for password reset or not: Having a dedicated webhook endpoint that handles only reacting to password change can help. this endpoint will be hooked to the after password settings flow. Checking the
active
and
state
could be sufficient to determine a successful password change.
if you want the data to set always, you can make kratos parse the response so the data generated by every successful recovery is consistent and up to date. if you cannot successfully update your data, it means kratos would not mark the password reset as completed.
i can test this and see what the outcome is like and share with you
a
basically, we are setting a flag in some users'
metadata_public
which will prevent them logging in until they have successfully reset their password. The login we can block just from jsonnet, but I don't think we can remove or change the flag just from the jsonnet - we have to make the webhook call to our api which uses the admin api to remove the flag. It's just a shame we can't do all of that on the Ory side and not have potentially unreliable network calls in the middle.
we more-or-less have it working with webhooks now but when one purchases an auth system, we kind of expected forcing a password reset to be included 🙂
g
Yes. Seems like so. I agree there should be an OOTB for this feature. Maybe someone from Ory can provide feedback. I see you dropped a feedback. Hopefully someone responds.