Microsoft Office 2010'un Subversion sunucusuyla Sharepoint gibi tümleştirilmesini engelleme


11

Tüm belgelerimizi (diğer şeylerin yanı sıra) sakladığımız bir Apache Subversion sunucumuz var. Svn'de çok sayıda Word, Excel, PDF vb. Dokümanımız var ve tüm kullanıcılarımız istemci arayüzü olarak TortoiseSVN kullanıyor. Bu kullanıcıların birçoğu da (ne yazık ki) genellikle Internet Explorer olan bir web tarayıcısı aracılığıyla repoya göz atacak.

Son zamanlarda Office 2010'u denemeye başladık (2003'ten geliyor) ve IE ile gezinirken depodaki belgelerin farklı açıldığını gördük. IE dosyayı indirmek ve daha sonra uygun uygulamaya göndermek yerine (daha sonra sadece yerel olarak saklanan geçici bir kopya olması gerekir), belgenin URL'sini uygulamaya gönderir . Doküman uygulama tarafından indirilir ve bir Sharepoint sunucusundan gelmiş gibi işlenir, yani uygulama onu kilitlemeye ve kaydedilen değişiklikleri otomatik olarak sunucuya geri yüklemeye çalışır.

Googling'den birçok insan bu davranışı istiyor gibi görünüyor . Ancak, devre dışı bırakmak istiyoruz - mevcut süreçlerimize uymuyor. Bunu nasıl yapabilirim?

İstemci makineleri üzerinde çok fazla kontrole sahip değilim, bu yüzden her müşteri için böyle tüm Office belgesi işbirliği özelliklerini devre dışı bırakmayı içeren çözümler aradığım şey değil. Ayrıca, IE'de Office Document Cache Handler eklentisini devre dışı bırakmak dışında yapabileceğim pek bir şey bulamadım. Mümkün olabilen tek istemci tarafı seçenekleri, adlandırılmış sunucumuz için bu özelliği özellikle devre dışı bırakan, ancak başkaları için açık bırakan seçeneklerdir.

Böylece sunucu tarafı çözümleri kalır. Office svn sunucusunun WebDAV desteğine sahip olduğunu ve bu nedenle Sharepoint benzeri bir belge yönetimi iş akışına geçtiğini gördüğünü tahmin ediyorum. Sunucudaki tüm WebDAV desteğini devre dışı bırakmadan bu tür bir entegrasyonu durdurmanın herhangi bir yolu var mı (bunu bile yapabileceğimizi varsayarak)? Aslında svn'nin otomatik geçişini başka amaçlar için biraz kullanıyoruz, bu yüzden gerekli bir özellik. Bir Sharepoint sunucusu olsa bile özelliği devre dışı bırakma tartışması buldum, ancak değil! Bu tür şeylerin nasıl çalıştığına dair anlayışım (örn. Sunucuda WebDAV desteğini tanımlayan Office istemcisi) oldukça sınırlıdır, bu yüzden lütfen mümkünse daha fazla açıklayın.

Önemli olması durumunda, sunucu kurulumu:

Ubuntu Hardy 8.04 üzerinde Apache v2.2.8 ve Subversion v1.4.6.


Bunu cevap olarak öneremem, çünkü bu daha hantal bir çözüm. Apache / SVN erişim protokolü olarak DAV kullandığından DFAV konusunda haklı olduğunuzu düşünüyorum. Bunu göz önünde bulundurarak Apache'yi bırakıp kullanabilirsiniz svnserve.
SmallClanger

Öneri için teşekkürler, ama svnserver bizim için bir seçenek değil. Apache'yi kullanarak bize bağlı çok sayıda özelleştirme var.
James Tisato

MS'den çok kullanışlı bir makale buldum (şaşırdım!): Support.microsoft.com/kb/838028 Apache sunucusunun HTTP 1.1 SEÇENEKLERİ yanıtıyla WebDAV işlemlerini yapabildiğini ve dolayısıyla Office'in bunları kullandığını gösteriyor gibi görünüyor . "Sunucumun WebDAV'ın kullanılabilir olmasını istiyorum, ancak Office'in bunu kullanmasını istemiyorum?"
James Tisato

Yanıtlar:


13

Çözüldü (sonunda). http://support.microsoft.com/kb/838028 Office'in, belge sunucusunun WebDAV özelliklerine sahip olup olmadığını belirlemek için Microsoft Office Protokol Bulma'yı nasıl kullandığını açıklar. Bir HTTP 1.1 SEÇENEKLERİ isteği gönderir ve kullanılabilir DAV özelliklerini ayrıntılı olarak gösteren bir 200 OK yanıtı bekler. Subversion sunucusu (sınırlı) DAV desteğine sahiptir ve bu şekilde yanıt verir ve Office daha sonra doğrudan sunucuya yazmak için kullanır.

Kullandığımız çözüm, bu isteklere müdahale etmek ve 405 Yöntemi İzin Verilmez yanıtı göndermek için Apache sunucusunda mod_rewrite kullanmaktı. Yeniden yazma yapılandırması:

# 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]

Aracılardan "Microsoft Office Protokolü Keşfi" adıyla gelen tüm OPTIONS yöntem isteklerini durdurur ve 405'i geri gönderir. Bu çözüm, http://rails.nuvvo.com/lesson/2318-dealing- raylar ile # microsoft-office-protokolü-keşif-yorumlar .

Şimdi Office birkaç SEÇENEK isteği deniyor, 405 tarafından reddediliyor, daha sonra bu belirli sunucu için tüm DAV desteğini bırakıp kapatırken, istemcilerin etkileşimde bulunmak isteyebilecekleri diğer sunucular için etkin durumda bırakıyor.


Çok teşekkür ederim! Subversion'ı kullanmama rağmen aynı temel sorunla mücadele ediyordum ve şimdiye kadar belge bulamıyorum. Emin budur ya hala% 100 değilim hepsi bunun ancak öyle gibi. Bir web sayfasına bağlı Office belgelerini açmak, kopyanın yerel bir önbellekten görüntülenmesi gerekmesine rağmen dahili köprüleri (göreceli, yolsuz) tam nitelikli http adreslerini yollarla tamamladı. Bu sadece IE'de oldu ... FF ve Chrome yerel dosya önbelleğinden (beklendiği gibi) bozuk bağlantılar gösterdi. Tekrar teşekkürler.
one.beat.consumer

1
@Chekolyn tarafından önerilen, yapılandırmayı yeniden yazmak için follwoing üç satır ekleyin: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

Excel HYPERLINK () çağrıları OPTIONS isteği oluşturmaz, ancak fazladan bir GET oluşturur. Onlarla birlikte izlenecek kullanıcı aracısı dizesi "ms-office" dir. 405 hatasını döndürmek, köprülerin düzgün çalışmamasına neden oldu, ancak Office için 200 boş bir yanıt döndürmek hile yaptı, URL'ye hemen hemen varsayılan web tarayıcısını açtı (IIS'de ASP.NET kullanıyorum, bu yüzden yaptım kimlik doğrulamasından önce).
richardtallent

Ancak şimdi bazı excel'lerde artık ms-office bulunmuyor. Örneğin 2013'üm bunu yapmıyor.
mplungjan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.