Etiquetas doTag en Java JSP

 Las siguientes líneas dentro de doTag proporcionan la implementación para escribir en la salida JSP a través de una serie de llamadas a out.println. Cualquier contenido que se pase a out.println se mostrará en la página. Tenga en cuenta que en el ejemplo,
se comprueba el campo
para ver si contiene un valor nulo. Si no contiene un valor nulo, entonces
se muestra en la página; de lo contrario, se omite. Por lo tanto, si la etiqueta dentro de la página JSP contiene un valor para el atributo authorName, se imprimirá en la página. El código out.println está contenido dentro de un bloque try-catch en caso de que ocurra alguna excepción.
■ Nota Para permitir que su etiqueta acepte scriptlets, deberá utilizar los controladores de etiquetas clásicos. Los controladores de etiquetas clásicos existían antes de la era JSP 2.0 y todavía se pueden utilizar junto con los controladores de etiquetas simples. Los controladores de etiquetas simples giran en torno al método doTag (), mientras que los controladores de etiquetas clásicos se ocupan de un método doStartTag () y un método doEndTag (), entre otros. Dado que los controladores de etiquetas simples se pueden utilizar junto con los controladores de etiquetas clásicas, es posible utilizar algunos de los métodos de etiquetas clásicas más complejos, al mismo tiempo que se utilizan métodos de etiquetas simples en la misma aplicación. Esto facilita la transición de los controladores de etiquetas clásicos a los controladores de etiquetas simples. Para obtener más información sobre las diferencias entre los dos aPI, consulte la documentación en línea mediante la búsqueda de las palabras clave Controladores de etiquetas simples y clásicos.
Eso es todo; la implementación de la etiqueta está completa. Para asignar la clase de implementación al Modelo de objetos de documento (DOM) a través de un nombre de etiqueta, un TLD debe contener una asignación a la clase. En el ejemplo, se crea un TLD llamado custom.tld y contiene el mapeo de la clase. El elemento short-name especifica el nombre que debe ser
utilizado dentro de la página JSP para hacer referencia a la etiqueta. El elemento uri especifica el nombre del TLD y se utiliza desde la página JSP para hacer referencia al archivo TLD en sí. La carne del TLD está contenida dentro del elemento de etiqueta. los
El elemento de nombre se usa para especificar el nombre de la etiqueta, y se usará dentro de una página JSP en combinación con el elemento de nombre corto para proporcionar el nombre de etiqueta completo. El elemento tag-class proporciona el nombre de la clase que implementa la etiqueta, y body-content especifica un valor para indicar si el contenido del cuerpo de la página JSP estará disponible para la clase de implementación de la etiqueta. Está configurado como vacío para este ejemplo. Para especificar un atributo para la etiqueta, el elemento de atributo debe agregarse al TLD, incluido el nombre, rtexprvalue y los elementos requeridos. El elemento name del atributo especifica el nombre del atributo, rtexprvalue indica si el atributo puede contener una expresión EL y required indica si el atributo es obligatorio.

Archivo de configuración rndc.conf

Primero veamos la configuración del comando rndc. La configuración del comando rndc se controla en dos lugares: en el archivo de configuración rndc.conf y mediante controles y declaraciones clave que necesita agregar al archivo de configuración named.conf.

El archivo de configuración rndc.conf contiene las opciones de configuración que especifican cómo el comando rndc se conecta al demonio nombrado. Este archivo también contiene un hash criptográfico, como el que usa TSIG (ver la sección “TSIG”), que autentica el comando en el canal de control. La declaración de controles en el archivo named.conf especifica las opciones para configurar el canal de control al que se conecta el comando rndc, y la declaración clave del archivo named.conf contiene una copia del hash criptográfico especificado en el archivo rndc.conf. Definido tanto en la configuración del comando rndc como en la configuración del servidor BIND, el hash criptográfico actúa como un secreto compartido. 

De forma predeterminada, el archivo rndc.conf se encuentra en / etc. Si ha chrooteado el demonio nombrado, necesita crear un enlace simbólico al archivo en la cárcel chroot; por ejemplo, usando la cárcel chroot creada en la sección "Chrooting BIND", crearía el enlace simbólico en el directorio / chroot / named / etc

El archivo rndc.conf puede contener tres tipos de instrucciones: opciones, servidor y clave. Estas sentencias usan la misma sintaxis que las sentencias named.conf, y todas deben terminar con punto y coma.
La primera declaración, opciones, especifica los valores predeterminados del comando rndc.

El servidor se puede especificar por dirección IP o nombre de host. Para la declaración d
el servidor, he especificado la dirección IP del host local 127.0.0.1. Para cada declaración de servidor, también debe especificar la clave que se utilizará para este servidor. Puede hacer esto usando la subenunciación clave.

BIND - Vistas Parte 2

 Las vistas deben tener un nombre y debe colocar el nombre entre comillas para permitir el uso de cualquier nombre, incluidas las palabras de configuración BIND protegidas. Para ello hemos definido una vista llamada interna. Después del nombre de la vista, he especificado su clase, IN. Esta es la clase de Internet y debería usarse para casi todas las vistas. Si no especifica una clase, BIND se establecerá de forma predeterminada en una clase de IN. Finalmente, el contenido de la vista está incluido entre llaves, y la última llave debe terminar con un punto y coma, en línea con el estilo estándar de instrucción de configuración named.conf.

La declaración de vista tiene tres secciones principales: las opciones de coincidencia del cliente, las opciones de vista y las zonas definidas en esta vista. La opción de coincidencia de clientes es necesaria para todas las vistas y, para ello, especifico la subenunciación de coincidencias de clientes. Esta sub-declaración le permite especificar los clientes particulares que pueden usar esta vista. Debe especificar esta subdeclaración para asegurarse de que la vista coincida con clientes particulares. En la subenunciado match-clients, he especificado un acl, de confianza, anteriormente en este capítulo. Esto configura BIND para que coincida con todas las direcciones especificadas en ese acl con esta vista. La opción match-clients también puede usar los parámetros normales de la lista de coincidencias de direcciones BIND, como direcciones IP, redes o claves.

También puede especificar una subenunciación de coincidencia de cliente adicional, destinos de coincidencia. La subdeclaración de destinos coincidentes le permite hacer coincidir los clientes por el destino al que se han conectado. También puede usar estas dos sub-declaraciones juntas para hacer coincidir el origen y el destino de un cliente.
Por último, también puede especificar la subenunciación solo recursiva de coincidencia, que indica que solo las consultas recursivas de clientes coincidentes se compararán con la vista. Otros tipos de consultas no coincidirán con la vista.

BIND - Declaración de vistas

La declaración de vista está vinculada a la declaración de zona y se introdujo en la versión 9 de BIND. La declaración de vista actúa como un contenedor para una serie de declaraciones de zona y le permite responder una consulta de DNS de manera diferente dependiendo de quién la esté preguntando. Por ejemplo, suponga que tiene un host bastión que ejecuta BIND y está conectado tanto a su red interna como a Internet. Al usar vistas, podría proporcionar una respuesta a una consulta de su red interna y una respuesta diferente a la misma consulta de Internet.
¿Por qué es útil esto? Bueno, puede ofrecerle dos ventajas. En primer lugar, puede permitir que un solo host BIND tenga autoridad simultáneamente para los dominios internos de su red y externos a Internet. En segundo lugar, puede permitir que un solo host BIND realice funciones de servidor y de almacenamiento en caché.
Entonces, ¿cómo ofrecen las vistas estas ventajas? Tomemos el host BIND meme.yourdomain.com. Es un host bastión conectado a la red local 192.168.0.0/24 con una dirección IP de 192.168.0.100 y también conectado a Internet con una dirección IP de 203.28.13.12. El dominio meme.yourdomain.com está autorizado para el dominio yourdomain.com. Desde la red interna, si alguien consulta el nombre de host mole.yourdomain.com, desea que el servidor BIND devuelva la dirección IP 192.168.0.10. 

Desde Internet, si alguien consulta el mismo nombre de host, desea que el servidor BIND devuelva su dirección IP de acceso a Internet, 203.28.13.13. Pero antes de tener vistas, solo podía definir una zona sudominio.com con un archivo de zona en un archivo named.conf. Esto significaba que no podía proporcionar ambas respuestas desde un solo host, a menos que estuviera ejecutando dos instancias de BIND. Esta configuración requería una sobrecarga considerable y era muy complicada de administrar.
Con las vistas puede definir una vista para cada tipo de consulta, interna o externa. 

Luego, hace coincidir los clientes entrantes con la vista adecuada. Luego, tiene dos zonas de sudominio.com definidas, una en cada vista y cada una con sus propios archivos de zona. Los clientes de la red interna recibirán respuestas de la vista interna y los clientes que realicen consultas desde Internet recibirán respuestas de la vista externa. Esto combina la funcionalidad de dos servidores BIND en un servidor.

Puede usar la misma funcionalidad de vista para proporcionar dos tipos diferentes de funcionalidad BIND, servidor y almacenamiento en caché, en un host. Con las vistas, puede hacer coincidir un conjunto de clientes (por ejemplo, cualquier cliente externo que no sea de confianza) con una vista que resuelve consultas solo para los dominios para los que tiene autoridad y no proporciona almacenamient
o en caché ni recursividad. Otro conjunto de clientes (por ejemplo, sus clientes internos de confianza) se puede hacer coincidir con una vista que permite el almacenamiento en caché y las consultas recursivas, pero no tiene autoridad para ningún dominio.