11 votos

Cómo evitar que Microsoft Office 2010 se integre con el servidor Subversion como si fuera Sharepoint

Tenemos un servidor Apache Subversion en el que almacenamos (entre otras cosas) toda nuestra documentación. Tenemos muchos documentos de Word, Excel, PDF, etc. en svn, y todos nuestros usuarios utilizan TortoiseSVN como su interfaz de cliente. Muchos de esos usuarios también navegarán por el repo a través de un navegador web, que (desafortunadamente) suele ser Internet Explorer.

Hace poco empezamos a probar Office 2010 (que viene de 2003) y descubrimos que los documentos del repo se abren de forma diferente al navegar con IE. En lugar de que IE descargue el archivo y lo envíe a la aplicación correspondiente (después de lo cual debería ser sólo una copia temporal almacenada localmente), envía el URL para el documento a la aplicación. La aplicación descarga el documento y lo trata como si procediera de un servidor Sharepoint, es decir, la aplicación intenta bloquearlo y, a continuación, carga los cambios guardados en el servidor automáticamente.

Al buscar en Google, parece que mucha gente quiere este comportamiento. Sin embargo, queremos desactivarlo, ya que no encaja con nuestros procesos actuales. ¿Cómo puedo hacerlo?

No tengo mucho control sobre las máquinas de los clientes, así que las soluciones que implican la desactivación de todas las funciones de colaboración de documentos de Office para cada cliente no son lo que estoy buscando. Además, no pude encontrar mucho que pudiera hacer aparte de desactivar el complemento Office Document Cache Handler en IE. Las únicas opciones del lado del cliente que pueden ser factibles son las que específicamente deshabilitan esta característica para nuestro servidor nombrado pero la dejan activada para los demás.

Así que quedan las soluciones del lado del servidor. Supongo que Office ve que el servidor svn tiene soporte para WebDAV y por lo tanto se mueve en un flujo de trabajo de gestión de documentos similar a Sharepoint. ¿Hay alguna manera de detener este tipo de integración sin deshabilitar todo el soporte de WebDAV en el servidor (suponiendo que podamos hacer eso)? En realidad usamos la autoversión de svn un poco para otros propósitos, así que es una característica necesaria. ¡He encontrado discusiones sobre la desactivación de la característica si es realmente un servidor Sharepoint, pero no lo es! Mi comprensión de cómo funciona este tipo de cosas (es decir, el cliente de Office identificando el soporte de WebDAV en el servidor) es bastante limitada, así que por favor explique más si puede.

En caso de que importe, la configuración del servidor es:

Apache v2.2.8 y Subversion v1.4.6 en Ubuntu Hardy 8.04.

0 votos

No puedo sugerir esto como respuesta, ya que es más bien una solución engorrosa. Creo que tienes razón sobre el DFAV, ya que Apache/SVN utiliza DAV como protocolo de acceso. Teniendo esto en cuenta, podrías dejar Apache y usar svnserve en su lugar.

0 votos

Gracias por la sugerencia, pero svnserver no es una opción para nosotros. Tenemos un montón de personalización en el lugar que depende de nosotros usando Apache.

0 votos

He encontrado un artículo muy útil de MS (¡me ha sorprendido!): support.microsoft.com/kb/838028 Parece que el servidor Apache indica a través de su respuesta HTTP 1.1 OPTIONS que es capaz de realizar operaciones WebDAV y por tanto Office las utiliza. ¿Dónde está la maldita opción para decir "quiero que mi servidor tenga disponible WebDAV, pero no quiero que Office lo utilice"?

13voto

justartem Puntos 13

Resuelto (por fin). http://support.microsoft.com/kb/838028 explica cómo Office utiliza Microsoft Office Protocol Discovery para determinar si el servidor de documentos tiene capacidades de WebDAV. Envía una petición HTTP 1.1 OPTIONS y espera una respuesta 200 OK detallando las características DAV disponibles. El servidor Subversion tiene soporte DAV (limitado) y responde como tal, y Office lo utiliza para escribir directamente en el servidor.

La solución que utilizamos fue usar mod_rewrite en el servidor Apache para interceptar estas peticiones y devolver una respuesta 405 Method Not Allowed. La configuración de reescritura es:

# Intercept Microsoft Office Protocol Discovery
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR]
RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$
RewriteRule .* - [R=405,L]

Intercepta todas las peticiones del método OPTIONS procedentes de agentes con el nombre "Microsoft Office Protocol Discovery" y devuelve un 405. Esta solución fue sugerida por el primer comentario sobre http://Rails.nuvvo.com/lesson/2318-dealing-with-microsoft-office-protocol-discovery-in-Rails#comments .

Ahora Office intenta unas cuantas peticiones de OPTIONS, es denegado por el 405, entonces se da por vencido y desactiva todo el soporte de DAV para este servidor en particular, mientras que lo deja habilitado para cualquier otro servidor con el que los clientes quieran interactuar.

0 votos

Muchas gracias. Aunque no estoy usando Subversion, he estado luchando contra el mismo problema del núcleo y no he podido encontrar documentación hasta ahora. Todavía no estoy 100% seguro de que esto es, o todo de ello, pero parece que sí. Abrir documentos de Office enlazados en una página web hacía que los hipervínculos internos (relativos, sin ruta) se convirtieran en direcciones http totalmente cualificadas con ruta aunque la copia debería estar siendo vista desde una caché local. Esto sólo ocurría en IE... FF y Chrome mostraban los enlaces rotos (como era de esperar) desde la caché local de archivos. Gracias una vez más.

1 votos

Sugerido por @chekolyn , añada las siguientes tres líneas a la configuración de reescritura: RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Protocol\ Discovery [OR] RewriteCond %{HTTP_USER_AGENT} ^Microsoft\ Office\ Existence\ Discovery [OR] RewriteCond %{HTTP_USER_AGENT} ^Microsoft\-WebDAV\-MiniRedir.*$

0 votos

Las llamadas de Excel HYPERLINK() no generan una petición OPTIONS pero sí una GET extra. La cadena de agente de usuario a tener en cuenta con ellas es "ms-office". Devolver un error 405 hizo que los hipervínculos no funcionaran correctamente en absoluto, pero devolver una respuesta 200 en blanco para Office hizo el truco, abrió el navegador web por defecto casi inmediatamente a la URL (estoy usando ASP.NET en IIS, así que hice esto antes de la autenticación).

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X