As part of adding unified login (#3712), we also centralized the password resetting functionality. The initial issue I was going to bring up is that we have a process running in each city to clear out expired password reset tokens from the auth_tokens table, but since the table is shared, it's overkill to have every city doing this.
As I think further, I think that it may have been a mistake to centralize this functionality. Maybe later on I'll remember why I did it in the first place, but for I don't see any benefit to it being done this way. You get an email with a password reset link. Now you could edit the link to change which server you're going to and it would still work; it seems like that's the only "benefit", but there's no reason why anyone would do that. So maybe we should just move it back to the separate cities' schemas!
Potential solution(s)
Moving back to the separate cities' schemas should be trivially easy. We just need to remove the explicit references to the sidewalk_login schema wherever we're using the auth_tokens table. We didn't delete the city-specific ones yet, so it will default back to using those if we remove the explicit references to the new schema.
Then I'll just delete the corresponding table that was added to the sidewalk_login schema.
Brief description of problem/feature
As part of adding unified login (#3712), we also centralized the password resetting functionality. The initial issue I was going to bring up is that we have a process running in each city to clear out expired password reset tokens from the
auth_tokenstable, but since the table is shared, it's overkill to have every city doing this.As I think further, I think that it may have been a mistake to centralize this functionality. Maybe later on I'll remember why I did it in the first place, but for I don't see any benefit to it being done this way. You get an email with a password reset link. Now you could edit the link to change which server you're going to and it would still work; it seems like that's the only "benefit", but there's no reason why anyone would do that. So maybe we should just move it back to the separate cities' schemas!
Potential solution(s)
Moving back to the separate cities' schemas should be trivially easy. We just need to remove the explicit references to the
sidewalk_loginschema wherever we're using theauth_tokenstable. We didn't delete the city-specific ones yet, so it will default back to using those if we remove the explicit references to the new schema.Then I'll just delete the corresponding table that was added to the
sidewalk_loginschema.