Can hitting rate limit invalidate password change tickets?

Help
,
1

Hi all,

As part of one of our batch account creation workflows, we use the /api/v2/tickets/password-change endpoint and send that along with a context-specific onboarding email.

For the first time, we hit the rate limit exception during this process (I am currently working on handling that better, and that is not directly my question). This rate limit incident coincided with multiple users encountering a “link expired” message on the password reset links. When this has happened previously, the problem is usually one of process - we send two emails, the second invalidates the first, and then the user clicks the expired link from the first email.

I’ll also note that we set “ttl_sec” to multiple days in this situation, and the recorded incidents all occurred within a 12 hour period between ticket generation and reported error.

So my question is - is it at all possible that hitting the rate limit somehow invalidated the recent tickets?

I am grasping as straws here to explain the expired links based on what is probably a coincidence, but I thought it was worth asking.

Thank you for your time,
John

2

The rate limit would simply prevent the current request from being processed so no password ticket would be issued as part of the rate-limited request. In other words, hitting the rate limit would not have any impact on previously issued tickets as you were already guessing.

The reset links should only be used once so are you sure the users experienced an error related to expiration? As in, is it possible that they reported issues about being unable to use the tickets, but was not strictly expiration?

For example, some email clients or email servers use products that may automatically visit/crawl links in received emails.

1 Like
3

Thanks for the response, and for validating that the ticket expiration issue has nothing to do with the rate limiter.

The users in this situation all reported seeing the language of “Expired”. I believe what they are seeing is the “Authentication Error - Access expired.” screen. Historically, I have seen this screen when a ticket expires by time.

Just now I conducted some tests to double-check UX.

  1. If I click a valid ticket multiple times, the ticket does not become invalid and continues to load the password change widget.

  2. If I generate a new password change ticket, the old ticket results in the “Authentication Error - Access expired.” screen.

  3. If I follow through with the password change process and later try to use the same spent ticket, the spent ticket loads the login widget rather than the password change widget or the “expired” screen.

I am fine with how this functions, but I thought it was worth noting because it seems to contradict what you suggest in your response about an email client that crawls links. Also, I want to clarify that by default “expired” language is used in situations not having to do strictly with time.

Anyways, it is good to know that there is no other way for tickets to become “expired”/invalid. I will keep investigating on my end.

Thanks again,
John