You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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_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 theauth_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.The text was updated successfully, but these errors were encountered: