Carolina, miembro de este equipo de trabajo, nos hizo el favor de crear esta sección ya que controla muy bien dicho tema.
Solución:
El conjunto de reglas de Apex de PMD está verificando que esté aplicando/respetando la seguridad en su código.
Los paquetes administrados de ISV publicados en AppExchange deben hacer esto como criterio obligatorio en el proceso de revisión de seguridad. El espíritu del requisito es cumplir con las opciones de configuración de control de acceso que los administradores de la organización hacen dentro de las ofertas de aplicaciones de ISV. Si un administrador restringe explícitamente el control de acceso para compartir/CRUD/FLS, las ofertas de ISV deben respetar eso.
Teóricamente, debería poder eliminar esta regla del conjunto de reglas PMD de VS Code (o crear un xml de conjunto de reglas personalizado que no lo incluya), si no desea recibir una advertencia sobre una inquietud que puede no aplicarse a su aplicación. situación.
Parece que el complemento VS Code PMD permite un conjunto de reglas personalizado. Puede tomar este aquí y personalizarlo, eliminando las reglas que no son importantes para usted, como esta:
Relacionado:
-
GitHub: PMD: conjunto de reglas de Apex
-
Aplicación de permisos de objetos y campos
-
Autorización y Control de Acceso
-
Trailhead: Prevención de infracciones CRUD y FLS
eliminar ese tipo de regla no es la solución, busque una solución adecuada y realice cambios en su código. Creo que los siguientes cambios en su código podrían ayudar.
SObject.sObjectType.getDescribe().isAccessible()SObject.sObjectType.getDescribe().isCreateable()SObject.sObjectType.getDescribe().isUpdateable()SObject.sObjectType.getDescribe().isDeleteable()SObject is Object which we want to try over
PMD no arrojará un error si sigue la siguiente sintaxis: –
List contacts = new List();
// Agrega un código para completar el nombre y el teléfono de los contactos. Antes de realizar dml, está verificando los permisos de nivel de objeto y campo como:
if(Contact.SObjectType.getDescribe().isAccessible() && Schema.SObjectType.Contact.fields.Name.isAccessible() && Schema.SObjectType.Contact.fields.Phone.isAccessible())
insert contacts;
Sin embargo, la buena noticia es que no tiene que verificar los permisos en la versión Spring 20. Puede manejarlo en la consulta en sí como: –
Contact c = [SELECT Email FROM Contact WHERE Id=:Id WITH SECURITY_ENFORCED];
Y antes de realizar un DML, puede eliminar los campos a los que el usuario no tiene acceso como:
SObjectAccessDecision decision = Security.stripInaccessible(AccessType.CREATABLE, contacts);
insert contacts;
Eche un vistazo a este enlace para obtener más información: – ¿Validar el permiso CRUD antes de la operación SOQL/DML? Bueno… eso es Historia