I have the problem that my rule is not being triggered. I have simplified it to a minimal version, but still it is not being called:
function (user, context, callback) {
return callback('Access denied');
}
When I run “Try this rule” everything works as expected and I can also see the message. But when I log into an API that is connected to this tenant the authentication is not triggered and the user logs in without any problems.
Of course the rule is “enabled”.
Is there any configuration/setting that I am missing?
I’ve run into the same problem which seems to only be with newly created applications. We have some old applications which when we use them to login, the rules are run but any applications created today do not.
I’ll just add that I’ve been trying to understand why my rules stopped to work around lunch today, so that is also about the same time as for you Dennis.
I have initially thought it was due to some misconfiguration on my tenant, but now I’ve reproduced using a minimal example
function (user, context, callback) {
//callback(null, user, context);
}
Note that I’ve commented out the last line in the rule, the one that calls the callback. This rule should thus not work, and should break the login process.
But, from my application I can login, as if the rule wasn’t executed.
On the other hand I go, in the Auth0 Dashboard, to Connections->Database Connections
And press the Try button (looking like a play button) on the right of my Auth0 located database… It times out.
Finally is this presented.
{
“error”: “access_denied”,
“error_description”: “Request to Webtask got ESOCKETTIMEDOUT”
}
Expected outcome:
I would expect that login from my application also would timeout. But that is not the case.
So it looks like the rule is not executed properly
I had the application working this morning, but I did some update to the rules, and suddenly I did not understand what was happening. For the moment it feels like any rules I add in the Dashboard will not be used.
We’ve been able to reproduce the issue internally. It’s just has been escalated to the team responsible for that part of the stack. Will provide you with an update on this soon!
The rules still don’t work for me. I’ve now the last 15 minutes disabled and reenabled them, I have edited rules, and still they do not seem to be run when tokens are issued for an application.
same here, just finished my setup process trying to add user_metatdata via rules,
and rules are not being called (no logs records) it only works with the “TRY ALL RULES…”
I tried to add new rules to an existing Auth0 tenant yesterday and again today but each time ran into this same issue. The rule is not executed as part of the login process from our website, but if I click the “Try all rules” on the dashboard the rule is executed as expected.
If I modify an existing rule everything is fine. However, in my case I would need to run a new rule before a rule generated by the Authorization extension, so I cannot create a work-around this way.
Do you have any ETA for the fix? This is blocking us from taking our project to production.
Thank you everyone for reporting those! For future reference you can always check our status websites to see what’s happening and what’s the potential ETA for solving this.
As far as I can see from our status page it should be resolved by now:
I noticed on the incident status link that this should already be working.
I have for 5 minutes ago tested, and no, my rules are not executing.
For instance I created this new rule:
function (user, context, callback) {
return callback(new UnauthorizedError(‘This app is unavailable due to tests’));
}
When I click on “Try all rules” in the dashboard, then selects the Username-Password-Authentication connection (=standard Auth0 database), I get the expected
{
“error”: “unauthorized”,
“error_description”: “This app is unavailable due to tests”
}
but I can still login from a SampleMvcApp, and the IDtoken is very fresh ( “updated_at”: “2019-03-07T13:18:11.719Z”)
So from my perspective this issue is not resolved.
@dennis.hellmich please for future reference if you ever come by similar thread please do not mark it as resolved unless it works for everyone. Thank you!
@olabackstrom i just reached back to the team. Will get back to you soon on what steps you should take then!
It seems like not all tenants affected have been fixed already.
For those who still have problems it is advisableI to remove and re-create the application that is having problems. Going for this solutions will delete all the settings you had for certain app in the dashboard but you can easily manage that by restoring all the settings using deploy-cli to backup clients and restore.
We’re still working on having all tenants-affected fixed. Will let you know once I have any update to share!
@konrad.sopala
I followed your workaround, so I removed the application in the dashboard, and recreated it.
(The rules now work.)
From my perspective this is good enough, since the app hasn’t gone public. But I’m not too happy about the possibility for something like this happen in future production, having more than 20h before a workaround is provided.
EDIT: clarified that the rules now work
(no logs records) it only works with the “TRY ALL RULES…”