Implicaciones del control de acceso cuando se amplía un mandato de controlador

De acuerdo con el modelo de programación de HCL Commerce, puede crear sus propias implementaciones de los mandatos de controlador existentes. En este caso, cree una nueva clase de implementación y, a continuación, asocie la nueva clase de implementación a la interfaz existente actualizando el registro de mandato.

La realización de una ampliación de este tipo tiene tres implicaciones potenciales relacionadas con el control de acceso:

  1. Efecto en el método getResources.
  2. Efecto en las políticas de control de acceso a nivel de mandato
  3. Efecto en las políticas de control de acceso a nivel de recurso

Efecto en el método getResources

Si está ampliando un mandato de controlador existente, lo que significa que se ejecutará la lógica existente del mandato así como la nueva lógica personalizada, el nuevo mandato será una subclase del mandato existente. El método performExecute de la nueva implementación llama al método performExecute de la superclase. Si el nuevo mandato no accede a ningún recurso nuevo que requiera protección, no tendrá que alterar el método getResources. Sin embargo, si se accede a nuevos recursos protegibles, el nuevo mandato deberá implementar su propio método getResources y en este método llamar al método getResources de la superclase, antes de implementar la lógica getResources propia.

Los resultados del método getResources de la superclase deben almacenarse en una variable de instancia privada de tipo AccessVector. Entonces se deberán añadir los resultados del método getResources local al final de este vector. Por ejemplo, la nueva clase de implementación contendrá código similar al pseudocódigo siguiente:


private AccessVector resources = null;

public AccessVector getResources() throws ECException {
 // First, get the resources from the original implementation
 resources = super.getResources();

 // Now, append the new resources

 ////////////////////////////////////////
 // Logic for getting new resources //
 // and appending to the vector.  //
 /////////////////////////////////////////

 return resources;
}

Si no está ampliando la lógica de un mandato de controlador existente, sino que está sustituyendo completamente la lógica, no deberá llamar al método super.performExecute en la nueva implementación. Entonces no necesitará llamar al método super.getResources desde dentro de su propia implementación. En lugar de ello, simplemente implemente su propio método getResources, como sea apropiado.

Efecto en las políticas de control de acceso a nivel de mandato

Las políticas a nivel de mandato para los mandatos de controlador constan de la acción "Execute" que se actúa en el recurso de mandato. El recurso de mandato se especifica mediante el nombre de interfaz. Al ampliar un mandato existente, el mandato sigue implementando la interfaz original y, en sí, la política existente a nivel de mandato es suficiente para mantener el control de acceso anterior a nivel de mandato. Por consiguiente, no es necesario ningún cambio.

Efecto en las políticas de control de acceso a nivel de recurso

Si ha creado una nueva implementación de un mandato existente y ha asociado esta implementación a la interfaz de ese mandato existente, no es necesario realizar cambios en las políticas de control de acceso a nivel de recurso.

Si, en lugar de ello, crea una nueva clase de implementación que amplía una implementación existente y en esta clase llama al método super.performExecute y también implementa una nueva interfaz, será necesario realizar cambios en las políticas de control de acceso a nivel de recurso.

En este último caso, si el nuevo mandato implementa el método getResources o hereda una implementación no trivial del método getResources del mandato base, será necesario realizar cambios de política a nivel de recurso. Normalmente, las políticas a nivel de recurso constan de la acción de mandato que actúa en el recurso de objeto de negocio. Dado que la acción es simplemente una representación de serie de la interfaz del mandato, generalmente es necesario añadir el nuevo mandato a los grupos de acciones del mandato base. Sin embargo, si el nuevo mandato altera la implementación base del método getResources devolviendo simplemente nulo (null), no se realizará ninguna comprobación de control de acceso para este nuevo mandato. Tenga en cuenta que si esto no se realiza cuidadosamente, el nuevo mandato se podría abrir para usuarios mal intencionados.

Cuando se modifican las políticas de control de acceso a nivel de recurso, los pasos generales a realizar son los siguientes:

  1. Localice el archivo defaultAccessControlPolicies.xml, que se encuentra en el directorio siguiente:
    • HCL Commerce Developer WCDE_installdir\Commerce\xml\policies\xml
  2. Realice una copia de este archivo. Por ejemplo, asigne un nombre al archivo myDefaultAccessControlPolicies.xml.
  3. En este nuevo archivo, debe definir la nueva interfaz como una acción nueva. Por ejemplo, añada lo siguiente:
    
    <Action Name="yourNewInterface"
             CommandName="yourNewInterface">
    </Action>
    

    donde yourNewInterface es el nombre de la nueva interfaz.

  4. A continuación, deberá buscar en el archivo para localizar todos los grupos de acciones a los que pertenecía la acción original y, a continuación, añadir la nueva acción.
  5. Si el nuevo mandato está actuando en recursos que el mandato base no especificaba anteriormente, el grupo de recursos de las políticas de control de acceso correspondientes también se deberán cambiar para adaptar los nuevos recursos.
  6. Una vez que haya completado los cambios en el archivo XML, podrá eliminar las secciones que no haya modificado. Asegúrese de conservar el texto que se encuentra antes de la etiqueta <Policies>.

    Por ejemplo, se está añadiendo un mandato denominado MyOrderItemAddCmd que se amplía de un mandato existente denominado OrderItemAddCmd. Dado que OrderItemAddCmdImpl implementa getResources(), el nuevo mandato se debe definir como una acción y, a continuación, se debe añadir a los grupos de acciones a los que pertenece OrderItemAdd:

    
    <?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
    <!DOCTYPE Policies SYSTEM "../dtd/accesscontrolpolicies.dtd">
    <Policies>
    <Action Name="com.xyz.MyOrderItemAddCmd"
    CommandName="com.xyz.MyOrderItemAddCmd">
    </Action>
    
    <ActionGroup Name="OrderCreateCommands" OwnerID="RootOrganization">
    <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
    </ActionGroup>
    
    <ActionGroup Name="OrderWriteCommands" OwnerID="RootOrganization"> 
    <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
    </ActionGroup>
    
    <ActionGroup Name="InterestItemReadCommands" OwnerID="RootOrganization">
    <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
    </ActionGroup>
    </Policies>
    
  7. Cargue la información de la nueva política en la base de datos.