How to enable time limit restriction check before sending OTP using HTOP generator Node

Setup
, , , , , ,
#1

Hi Team,

I have a requirement to put a time-based limit for sending OTP, so the requirement is that before sending OTP using OTP generator or sender we can put a restriction that the following user should have limit of only 5 OTP in 30 min duration, if user has retry the OTP or trigger the OTP tree for 6 th times within 30 min of login then it should go for message like ‘try after 30 min’, Can we have a check on how many times does the OTP generator node has been trigger for the following user and when was the first time it got trigger and the latest time and count.

Please advice.

Regards

#2

You can use retry limit decision Retry Limit Decision node :: AM 7.3.1

But for duration purposes you can use AM Console, authentication, settings account lockout tab

#3

Hi @SelinKamasYilmaz,

Thankyou for your reply.

But before using retry limit decision, we have to check for the condition like if the user has trigger for OTP Journey and the before HTOP generator node this condition should be fulfilled like OTP generated for user is under 5 times and its under 30 min.
If I user account lockout setting then it will be lock the account and in my scenario no user will be locked out only the OTP will be restricted.

#4

[quote=“TanaySinha49, post:3, topic:5765”]
You can add retry limit decision after otp collector node or I wrote my own scripted decision node to collect otp node and put our own logic there.

Account Lockout is not option then for you, you use scripted decision node with timers maybe

#5

Does FR saves count for of OTP generated for the user and if yes how we can fetch it in script.

#6

I would take a different approach as such properties do not span the Authentication Session.
If we can agree that each request of an otp implies a new authentication session then, I would store the count-otp and time-otp in the user profile. Then, your necessary business rules may be applied via script, sourcing such criteriafrom the profile.

Of course, the complication is, how can you be guaranteed that the user profile is in fact in scope and not the target from the unauthorized, if authentication never completed?