#Security improvements

Further to my previous comment, i’ve updated the merge request and attached a new patch that includes support for #config_target on the salesforce_auth_form.

Previously, I noted that the form did not work out of the box with the Config Override Inspector (COI) module because it lacked the necessary context to identify which configuration keys the form elements relate to. I was working around this by injecting ['#config']['key'] values using a custom hook_form_alter().

With this patch, that workaround is no longer necessary. Adding #config_target directly to the form provides the needed context. This benefits both COI and Drupal core, as core’s config override system (since Drupal 10.2) now uses #config_target for identifying and reacting to overridden config values.

I have also submitted a patch to the COI module to support #config_target, which complements this change:
https://www.drupal.org/project/coi/issues/3409747#comment-16201736 📌 Use the new #config_target Form API property Active

Together, these updates ensure that configuration override behaviour works as expected, without requiring contrib or custom modules to add missing metadata.

Let me know if any adjustments are required.

I think we could use 📌 Add a classloader that can handle class moves Active now to alias it to an empty class somewhere, or hard-code similar behaviour somewhere earlier. Maybe a valid class that throws exceptions in every method or something?

The issue and linked PR are going nowhere fast.

I think we should consider replacing the class in Drupal core (per #3), removing it via composer, or removing it from the autoloader if that's feasible.

any updates?