Login With Limited Attempts

Wappler General Need Help
1

Hi.
I have security provider, login, restrict & logout setup working for me.
Now I have come across a use case where I need to allow limited number of unauthorized attempts.
The security login automatically sends back a 401 when login fails. How can I capture that in server action itself and run an update query to record a login attempt count, and then send a response back using a response step?

2

Hi @sid,

I remember this being brought up before, but I am not sure if the user got it to work or not.

1 Like
3

Hey @scott, thanks for the links. It seems there is no option for this yet. It is quite weird and not a good approach to rely on client side at all imo.

@Teodor any updates to this besides the answer you suggested in July?

4

hi @sid ,
you can do this easly.

  1. create table “login_attempts” fileds – > id, username, ip , datetime (or timestamp),
  2. create server action but it must be conditionaly
    when user try to login

  • false
    check user ip
    insert time , ip , user name , and datetime
    SELECT COUNT(*) FROM login_attempts WHERE ipAddress LIKE ‘$ip’
    AND timeDiff > diff and username =‘abcdeUser’
    and last step is count login attempt count>3 --> “You are allowed 3 attempts in 10 minutes”

  • true

    check user ip
    insert time , ip , user name , and datetime
    SELECT COUNT(*) FROM login_attempts WHERE ipAddress LIKE ‘$ip’
    AND timeDiff > diff and username =‘abcdeUser’
    count =< 3
    security provider
    login process

1 Like
5

Hi @s.alpaslan, thanks for the input.
What I am looking for is a solution based on security restrict.

With the solution you have proposed, it means same user cannot login from multiple devices at the same time from same IP.
Ideally, that should not be a problem… and if I can’t find a solution where I don’t have to add extra steps in my server action, I will probably use it.

6

no you will use ip and username in your query.

SELECT COUNT(*) FROM login_attempts WHERE ipAddress LIKE ‘$ip’
AND timeDiff > diff and username =‘abcdeUser’

7

If abcdeUser is logging in from multiple devices, using the same internet connection, IP will be same.

Like I wrote, its unlikely, but possible.

8

if user doesnt know correct password how can he/she loggin with different device… maybe I don’t know exactly what you want to achive.

9

If you insist on everything happening in the server action, why not do it the following way:

  • Database Query step (filter by entered username AND password)

  • Condition step (use the query as an expression)
    -- Then (the query returns results)

    • Login step

    -- Else (the query returns no results, i.e. wrong login details)

    • Update step
1 Like
10

Thats similar to what Serhat suggests…
but this means I am redoing what security provider and restrict is already doing…

The reason why I am hoping for a better solution is that we can already do stuff in server action by adding steps when login passes. But nothing when it fails.

1 Like
11

Well as i already explained a few months back … then create a separate server action and call it via dynamic events on your page.
That’s the recommended way of doing this and that’s why there are dynamic events responding to the different statuses.

12

That does not look like a “secure” enough solution.
Or is it good enough?
(Always skeptical abt this stuff. :sweat_smile: )

13

Secure?
What has this to do with the security? Your security is managed with the security provider…

14

The purpose is to block user after X number of unsuccessful attempts. So it is part of securing and restricting access to the system.

15

I still don’t get what do you think is not secure?
You run the login action, it sends back 401, this triggers the update action, which updates your database.

16

I’m just skeptical about this stuff. I gladly use the security provider ever since started developing on Wappler. So don’t think about securing this part of the app. But in this case, checking number of failed attempts is an additional piece… and I am not liking that I can’t handle it directly and have to rely on client side to know that login has failed.

But if you say this method is safe, I’ll handle it via dynamic events.

17

The most secure way would be to handle it all server-side in the same call, when having the update in a second call then it is possible to block it and the restriction won’t help.

I believe the security provider login doesn’t allow steps after it, but you could have a step in front of it. Update your database before the login step and check if the maximum is not reached. If the maximum is reached then do no login and return for example a 400 response with a message that the user reached the limit. You reset the attempts counter after a successful login, this can be placed inside the event in a second call to the server. Also you would probably want to set the last attempt datetime in the database, then you can reset the attempts also after a period of time.

1 Like
18

You read my mind. I was thinking along these lines, but you present it in much better way.
Thanks for the help.

Would it be possible to design a try catch thing for security provider so that the unauthorised event also gets captured server side?

19

We could perhaps introduce a flag that it should just return a Boolean that the login was successful and that it doesn’t end with a 401 response. Then you can have your own logic after the login step.

3 Likes
20

That would be ideal. :slight_smile: