En esta sección se debate en términos generales como interactúan el cliente y servidor Subversión entre sí, independientemente de la implementación de red que esté utilizando. A su término, usted comprenderá como se comporta un servidor y las diferentes formas en que un cliente puede ser configurado para responder.
El cliente Subversion insume la mayor parte de su tiempo manejando copias de trabajo. No obstante, cuando necesita información del repositorio efectúa una solicitud a través de la red, y el servidor responde apropiadamente. Los detalles del protocolo de red son ocultados por el usuario; el cliente intenta acceder a una URL, y dependiendo del esquema URL, utiliza un protocolo particular para contactar al servidor (ver URLs del repositorio). Los usuarios pueden ejecutar svn --version para ver que esquemas URL y protocolos que comprende el cliente.
Cuando el proceso del servidor recibe una solicitud del cliente, típicamente demanda que el cliente se identifique. Este solicita la autenticación al cliente , y el cliente responde proporcionando las credenciales al servidor. Una vez completado ésto, el servidor responde con la información que el cliente solicitó originalmente. Observe que este método se diferencia de sistemas como CVS, dónde el cliente por cuenta propia ofrece las credenciales (“de acceso al sistema”), antes de realizar una solicitud. En Subversion, el servidor “exige tomar” las credenciales a través de la negociación con el cliente en el momento apropiado, en lugar de que el cliente las “impulse”. Esto asegura operaciones más elegantes. Por ejemplo, si se configura un servidor para que permita acceso de lectura al repositorio a todo el mundo, nunca demandará a un cliente que se autentique cuando intente realizar un svn checkout.
Si la solicitud de red del cliente escribe datos nuevos
en el repositorio (por ejemplo: svn commit), un nuevo
árbol de revisión es creado. Si la solicitud del cliente fue
autenticada, el nombre del usuario es guardado como valor de la
propiedad svn:author en la nueva revisión
(ver “Propiedades no versionadas”). Si el cliente no
fue autenticado (en otras palabras, si el servidor nunca
promulgó la autenticación), la propiedad svn:author
de la revisión está en blanco.[27]
Muchos servidores son configurados para requerir autenticación por cada solicitud que reciban. Esto puede convertirse en una gran molestia para los usuarios, quienes son forzados a escribir sus contraseñas una y otra vez.
Afortunadamente, el cliente Subversion ha remediado ésto: un
sistema incorporado para ocultar las credenciales en el disco.
Por defecto, en el momento en que el cliente se autentica
satisfactoriamente con un servidor, éste guarda las credenciales
en el área de configuración de ejecución privada del usuario— en
~/.subversion/auth/ en los sistemas tipo
Unix o %APPDATA%/Subversion/auth/ en Windows.
(El área de ejecución es cubierto con mayor detalle en “Área de configuración de parámetros de ejecución”.) Con éxito las credenciales son
ocultadas en el disco, encerradas en una combinación de hostname,
puerto y realm de autenticación.
Cuando el cliente recibe la solicitud para que se autentique, primero busca las credenciales apropiadas en el caché de disco; sino existen, o si las credenciales fallan en la autenticación, el cliente simplemente pregunta al usuario por la información.
Las personas que sufren de paranoia sobre asuntos de
seguridad pueden estar pensando,
“Contraseñas ocultas en el disco? Eso es terrible!” Pero
por favor conserve la calma. Primero, el área de caché auth/
se encuentra protegida por permisos a fin de que sólo el
usuario (dueño) puede leer la información que se encuentra en
ella, evitando que otros puedan acceder. Si
eso no es lo suficientemente seguro para usted, puede deshabilitar
el caché de credenciales. Para
lograrlo, sólo basta con un único comando, pasando la opción
--no-auth-cache:
$ svn commit -F log_msg.txt --no-auth-cache Authentication realm: <svn://host.example.com:3690> example realm Username: joe Password for 'joe': Adding newfile Transmitting file data . Committed revision 2324. # password was not cached, so a second commit still prompts us $ svn rm newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe [...]
O, si usted desea deshabilitar el caché de credenciales en forma
permanente, puede editar su archivo de configuración config
(ubicado dentro del directorio auth/).
Simplemente coloque no a store-auth-creds,
y las credenciales no serán guardadas en el caché nunca más.
[auth] store-auth-creds = no
Algunas veces los usuario desearán eliminar credenciales
específicas del caché de disco. Para hacer ésto, necesitará
navegar dentro del área auth/ y eliminar
el archivo de caché apropiado en forma manual. Las credenciales
son almacenadas en el área de caché en archivos individuales; si
usted mira dentro de cada archivo, verá claves y valores. La clave
svn:realmstreng describe el "realm" servidor
particular con el que que el archivo es asociado:
$ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END
Una vez que haya localizado el archivo de caché apropiado, sencillamente elimínelo.
Una última palabra acerca del comportamiento de autenticación
del cliente: es necesaria una pequeña explicación respecto de
las opciones --username y --pasword.
Muchos sub-comandos del cliente aceptan estas opciones; sin embargo,
es importante comprender que la utilización de las mismas
no envía automáticamente las credenciales
al servidor. Como se dijo anteriormente, el servidor
“exige tomar” las credenciales del cliente cuando lo
considera necesario; el cliente no puede “impulsarlas”
a voluntad. Si un usuario y/o contraseña son pasados como opción,
ellos serán presentados al servidor sólo si este
así lo demanda.
[28]
Típicamente, estas opciones son utilizadas cuando:
el usuario desea autenticarse con un nombre diferente a su usuario de sistema, o
un guión desea autenticarse sin utilizar las credenciales del caché.
Aquí hay un resumen final que describe como se comporta un cliente Subversion cuando recibe la demanda de autenticación:
Verifica si el usuario ha especificado algunas credenciales
como opción de línea de comando, a través de la opción
--username y/o --pasword. Sino, o
si esas opciones no pertenecen a una autenticación válida, entonces
Busca en el "realm" del servidor en el área de ejecución
auth/, para ver si el usuario ya dispone de credenciales
apropiadas en el caché. Sino, o si las credenciales del caché fallan
en la autenticación, entonces
Recurre a preguntarle al usuario.
Si el cliente se autentica correctamente a través de alguno de los métodos listados aquí arriba, éste intentará guardar en las credenciales en el caché de disco (a no ser que el usuario haya deshabilitado ese funcionamiento, como hemos mencionado anteriormente.)
[27] Este problema es actualmente una FAQ, como resultado de una configuración equivocada de la instalación.
[28] Una vez más, un error frecuente es
configurar de forma equivocada el servidor para que este
nunca emita una demanda de autenticación. Cuando los usuarios pasen
la opción --username y --pasword
al cliente, ellos se sorprenderán al ver que éstos nunca son
utilizados, es decir, a pesar de aparecer una nueva revisión, ha sido enviada
anónimamente!