7 ms·
The part of that that I don't get is how a new user could have the same ID as an old (truncated) user since "our system created new records for them, with prima
by catfood 8y ago
The part of that that I don't get is how a new user could have the same ID as an old (truncated) user since "our system created new records for them, with primary keys generated from the existing sequence (PostgreSQL does not reset id sequences on truncate)."
Do they mean that the only potentially exposed accounts are those that signed up after the database was restored?
- cyrusaf 8y agoIt's possible their truncate also restarted the sequence: "TRUNCATE TABLE users RESTART IDENTITY;" https://stackoverflow.com/questions/13989243/sequence-does-not-reset-after-truncating-the-table?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa https://stackoverflow.com/questions/13989243/sequence-does-n... Although, I am confused about how sign ins created new users. When they say sign ins, do they mean new accounts?
- catfood 8y agoYeah they must mean new accounts, if not then I'm lost. I guess it could have reset autoincrement but they said it didn't. The only other thing I can think of is that the signed token that's put in localStorage is sent to the server like "someuser|sometoken", the server inspects sometoken, says it checks out, then takes the client at its word that it's someuser.
- inopinatus 8y agoA sign-in can result in an automatic account creation when using federated identity.
- bpicolo 8y agoYeah, it mentions that it's only accounts created after restore.