loginAttempts not getting reset to 0 on successful login, how to fix ?

[geminigeek]

hi,
currently loginAttempts retain the value they have even after a successful login, they should ideally be reset to 0 , on a successful login.

[DanRibbens]

That is exactly how it currently works. If the loginAttempts is not getting set to 0 on login, there must be a bug or something preventing it from updating in your own project. Do you have any hooks on the users collection or anything else that may be interfering?

[geminigeek]

hi,

i am adding auth params from a plugin can this be an issue ? , i am on payload version 2.27.0
i am using mongodb standalone 7.0.14 , no transaction support. can this be the reason ?

here is my relevant plugin config

 userCollection = {
    ...userCollection,
    auth: {
      ...(userCollection?.auth ?? {}),
      tokenExpiration: parseInt(process.env.PAYLOAD_JWT_EXPIRY), // 1 hours
      verify: true,
      maxLoginAttempts: 5,
      lockTime: 600 * 1000, // lock time in ms
      useAPIKey: false,
      depth: 0,
      cookies: {
        secure: process.env.COOKIE_SECURE === 'true' ? true : false,
        sameSite: 'lax',
        domain: process.env.COOKIE_DOMAIN,
      },
    },
}

[wkentdag]

I'm having the same issue on v2.23.1, no hooks on my user collection. My config looks similar to OP's...could access control be a contributing factor?

I'd be happy to submit a bug report and fix if the team will accept one. I'm currently manually flushing login_attempts and lock_until in the db for my users who trip the threshold.

  auth: {
    useAPIKey: true,
    verify: true,
    tokenExpiration: 60 * 60 * 60, // 1hr
    cookies: {
      sameSite: 'none',
      secure: true,
      // nb: the frontend uses payload cookies for preview mode auth,
      // so it also needs to be hosted under the same AUTH_TLD.
      // by default, the cookie domain is assigned to the `serverURL` domain
      ...(process.env.AUTH_TLD ? { domain: process.env.AUTH_TLD } : {}),
    },
  },

[geminigeek]

I'm having the same issue on v2.23.1, no hooks on my user collection. My config looks similar to OP's...could access control be a contributing factor?

I'd be happy to submit a bug report and fix if the team will accept one. I'm currently manually flushing login_attempts and lock_until in the db for my users who trip the threshold.

  auth: {
    useAPIKey: true,
    verify: true,
    tokenExpiration: 60 * 60 * 60, // 1hr
    cookies: {
      sameSite: 'none',
      secure: true,
      // nb: the frontend uses payload cookies for preview mode auth,
      // so it also needs to be hosted under the same AUTH_TLD.
      // by default, the cookie domain is assigned to the `serverURL` domain
      ...(process.env.AUTH_TLD ? { domain: process.env.AUTH_TLD } : {}),
    },
  },

I am resetting it manually also, the code looks fine in payload code, even the admin login is not resetting the login_attempts, are you using mongodb with no transaction? It seems this is a transaction issue?

[wkentdag]

no, i'm on postgres

[wkentdag]

i can't reproduce the issue on a fresh install create-payload-app@latest login-attempts-repro and postgres as DB (payload 2.30.1). must be something in our configs 🤔