Historically, some backends do not use optimal identifiers for users (like #1951). Changing the ID_KEY now breaks all existing authentications. I think it should be possible to support migration to different ID_KEY.
- Add
id_key to the UserMixin (and AbstractUserSocialAuth in the Django app).
- Upon authentication, first look for
id_key matching id_key() (exact matches).
- Fallback to matching
uid with a blank id_key (migration path for existing entries without it).
- Attempt fallback against
extra_data (this should handle the changed setting, but the question is whether extra_data actually contains all needed bits).
- The
id_key and uid would then be updated accordingly.
Historically, some backends do not use optimal identifiers for users (like #1951). Changing the
ID_KEYnow breaks all existing authentications. I think it should be possible to support migration to differentID_KEY.id_keyto theUserMixin(andAbstractUserSocialAuthin the Django app).id_keymatchingid_key()(exact matches).uidwith a blankid_key(migration path for existing entries without it).extra_data(this should handle the changed setting, but the question is whetherextra_dataactually contains all needed bits).id_keyanduidwould then be updated accordingly.