Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/27/2025 in all areas

  1. Correct. That is an invalid mysql date. You can set a mode of mysql to accept that value, but that is not the way to handle this problem. Instead, make sure that the OTP expiry allows NULL. Then set the value to NULL. Personally, I would not design a system like this. Instead I would have a related table that only holds "events". I will usually have an user_event_type table that has different allowable authentication events. For example: user event type id | Description 1. Registration 2. Password Reset 3. One time Password 4. Login 5. Close account 6. Failed Login 7. Account locked etc. I don't know what your user table looks like but hopefully it has an ID other than "email". I'll assume you do. So you then have a user_event table with a structure like this: id | user_id | user_event_type_id | event_value | status | expire_date_time | created_at 100| 245 | 3 | xyzabc... | 0 | ..... | current_date There are a few reasons to do this. They include: - you have an audit trail of events - MySQL with InnoDB is optimized for insert queries, and they don't reduce concurrency unlike update queries. Instead of trying to overwrite the OTP, you can simply set the status from 0 to 1 (or whatever value you want). You could have several status values if you want fine grain control over the changes in status. Just to keep it simple, if the person logs in with the OTP, then it's used, so you set the status to 0. A subsequent query of "SELECT * FROM user_event WHERE user_id = 245 and user_event_type = 3 AND status = 0 ORDER BY created_at DESC LIMIT 1" will always find the most recent OTP request. You can then compare that with the OTP value. Making event_value a varchar of a specific length is no cost if the field is unused, as varchars will use the bytes required. So if you want to use event_value for additional data, you can do that, but if it's something simple like "login" event, you don't need to use it. Personally I would also have a client_ip field in a table like this, where I use a varbinary field to store the IP. This works for both IPv4 and IPv6 addresses, but there are some tricks to doing that, and it is not specifically related to your question. I mention it just to be complete.
    1 point
This leaderboard is set to New York/GMT-04:00
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.