Open annabunches opened 4 years ago
Findings so far (a bit rambly, more succinct updates when I know more):
restricted_save
method, which doesn't allow the field to be written, see:Member::save
is called directly appears to be in the mass edit code:Member::save
does get called directly, it will pass in any field it receives. It massages certain fields, but does not clamp to fields that are defined / known to exist. So hypothetically if someone were to add POST data directly, we might try to write that. Seems unlikely that we have clients that are using the mass edit route in an automated fashion, (with possibly deprecated input) but I don't know the architecture of all possible "clients" well enough to be certain.Additional findings:
Member::save
, empirical testing so far has not revealed any way to set password_plaintext
- injecting the appropriate form parameter on the /members/add
route does not result in the value being set in the database.Update on this: shortly after the last comment in here we determined that the field is not in use by anything, and also that it is not populated, so this became a much lower-priority issue.
The members table has this field. It probably shouldn't. My recommendations: