Evitar que Microsoft Office 2010 se integre con el servidor Subversion como si fuera Sharepoint

10

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 usan TortoiseSVN como su interfaz de cliente. Muchos de esos usuarios también explorarán el repositorio a través de un navegador web, que (desafortunadamente) a menudo es Internet Explorer.

Recientemente comenzamos a probar Office 2010 (desde 2003) y descubrimos que los documentos del repositorio se abren de manera diferente cuando se navega con IE. En lugar de que IE descargue el archivo y luego lo envíe a la aplicación adecuada (después de lo cual debería ser solo una copia temporal almacenada localmente), envía la URL del documento a la aplicación. La aplicación descarga el documento y luego lo trata como si viniera de un servidor Sharepoint, es decir, la aplicación intenta bloquearlo y luego cargar los cambios guardados en el servidor automáticamente.

En Google, parece que muchas personas quieren este comportamiento. Sin embargo, queremos deshabilitarlo, no encaja con nuestros procesos existentes. ¿Cómo puedo hacer esto?

No tengo mucho control sobre las máquinas cliente, por lo que las soluciones que implican deshabilitar todas las funciones de colaboración de documentos de Office como esta para cada cliente no son lo que estoy buscando. Además, no pude encontrar mucho más que deshabilitar el complemento Office Document Cache Handler en IE. Las únicas opciones del lado del cliente que pueden ser factibles son aquellas que deshabilitan específicamente esta función para nuestro servidor nombrado pero la dejan activada para otros.

Eso deja soluciones del lado del servidor. Supongo que Office ve que el servidor svn tiene soporte WebDAV y, por lo tanto, pasa a un flujo de trabajo de gestión de documentos similar a Sharepoint. ¿Hay alguna forma de detener este tipo de integración sin deshabilitar todo el soporte de WebDAV en el servidor (suponiendo que incluso podamos hacerlo)? De hecho, utilizamos un poco la versión automática de svn para otros fines, por lo que es una característica obligatoria. He encontrado una discusión sobre cómo deshabilitar la función si en realidad es un servidor Sharepoint, ¡pero no lo es! Mi comprensión de cómo funciona este tipo de cosas (es decir, el cliente de Office que identifica el soporte de WebDAV en el servidor) es bastante limitada, así que explique más si puede.

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

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

James Tisato
fuente
No puedo sugerir esto como respuesta, ya que es una solución más engorrosa. Creo que tienes razón sobre el DFAV, ya que Apache / SVN usa DAV como su protocolo de acceso. Con eso en mente, puedes dejar Apache y usarlo svnserveen su lugar.
SmallClanger
Gracias por la sugerencia, pero svnserver no es una opción para nosotros. Tenemos mucha personalización en el lugar que depende de nosotros usando Apache.
James Tisato
Encontré un artículo muy útil de MS (¡me sorprendió!): Support.microsoft.com/kb/838028 Parece que el servidor Apache indica a través de su respuesta de OPCIONES HTTP 1.1 que es capaz de operaciones WebDAV y, por lo tanto, Office las usa . ¿Dónde está la maldita opción de decir "Quiero que mi servidor tenga WebDAV disponible, pero no quiero que Office lo use?"
James Tisato

Respuestas:

12

Lo resolvió (finalmente). http://support.microsoft.com/kb/838028 explica cómo Office usa Microsoft Office Protocol Discovery para determinar si el servidor de documentos tiene capacidades de WebDAV. Envía una solicitud de OPCIONES HTTP 1.1 y espera una respuesta de 200 OK que detalla las características DAV disponibles. El servidor Subversion tiene soporte DAV (limitado) y responde como tal, y Office luego lo usa para escribir directamente al servidor.

La solución que utilizamos fue utilizar mod_rewrite en el servidor Apache para interceptar estas solicitudes y enviar una respuesta 405 Método no permitido. 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 solicitudes de opciones de método que provienen de agentes con el nombre "Microsoft Office Protocol Discovery" y envía un 405. Esta solución fue sugerida por el primer comentario en http://rails.nuvvo.com/lesson/2318-dealing- with-microsoft-office-protocol-discovery-in-rails # comentarios .

Ahora Office intenta algunas solicitudes de OPCIONES, el 405 lo rechaza, luego se da por vencido y apaga todo el soporte DAV para este servidor en particular, mientras lo deja habilitado para cualquier otro servidor con el que los clientes quieran interactuar.

James Tisato
fuente
Muchas gracias! Si bien no estoy usando Subversion, he estado luchando contra el mismo problema central y no he podido encontrar documentación hasta ahora. Todavía no estoy 100% seguro de que sea esto, o todo , pero parece que sí. Al abrir documentos de Office vinculados en una página web, los hipervínculos internos (relativos, sin ruta) calificaron las direcciones http totalmente con ruta aunque la copia se debería ver desde un caché local. Esto solo sucedió en IE ... FF y Chrome mostraron enlaces rotos (como se esperaba) del caché de archivos local. Gracias otra vez.
one.beat.consumer
1
Sugerido por @chekolyn, agregue las siguientes tres líneas para reescribir la configuración: 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.*$
HopelessN00b
Las llamadas de Excel HYPERLINK () no generan una solicitud de OPCIONES pero generan un GET adicional. La cadena de agente de usuario a vigilar con ellos es "ms-office". Devolver un error 405 hizo que los hipervínculos no funcionaran correctamente, pero devolvió una respuesta 200 en blanco para Office, abrió el navegador web predeterminado casi inmediatamente a la URL (estoy usando ASP.NET en IIS, así que lo hice) esto antes de la autenticación).
richardtallent
Sin embargo, ahora algunos sobresalientes ya no tienen ms-office en ellos. Por ejemplo, mi 2013 no.
mplungjan