Posts Tagged ‘WebEdit’

Turn WebEdit OFF in IIS for WebCenter Interaction Collaboration Server

Monday, March 25th, 2013

We’ve had a good run with WebEdit functionality in the old Plumtree / ALUI / WebCenter Collaboration Server. There comes a time, though, when the pain/cost is increasing and the benefit/payback of fixing the issues is decreasing.

Such was the case at a client was getting this security prompt every time they tried to open an Office document that had been uploaded to Collaboration server through WCI:
office-security-prompt

It turns out that when Office 2010 opens a document from a web page, the first thing it tries to do after downloading the document is execute a WebDAV request (PROPFIND) to that server:
propfind
This makes all kinds of sense from Microsoft’s perspective – if a Word document is opened from a web site, first check to see if it’s a SHAREPOINT site, right? That way Office can enable all those neat WebEdit/WebDAV features automatically.

The problem was that IIS was choking on this request because Windows Integrated Authentication was prompting for the user’s domain credentials – and even if the proper user/pass was supplied to IIS, the portal still had no idea what to do with those WebDAV verbs.

The solution: just kill off WebDAV entirely in this portal instance. You do this by changing the verbs for the portal virtual directory (.pt extension) to only accept the verbs “GET,HEAD,POST”:

iis-verbs

This way, even if Office does try to check the WebDAV verbs, IIS is going to deny those requests before even letting them through to the portal, which probably wouldn’t know what to do with them anyway.

Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

Thursday, March 24th, 2011

If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.

Why?  This post by gimble2 about sums it up:

Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.

Indeed, this is a big problem because Java 1.6.0_24 lies to users:

Unrestricted Access, huh? Bullsh*t.

You can confirm this by viewing the Java Console when trying to run Bulk Upload:

There you’ll likely see an exception like this:

Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
Exception occurred during event dispatching:
java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. chooseFiles(BulkUploadApplet.java:191)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. access$100(BulkUploadApplet.java:15)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet$ 1FileChooserDisplayer.run (BulkUploadApplet.java:329)

at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

(more…)

Office 2010 WebEdit Corrupts Document Downloads

Friday, March 18th, 2011

We’ve now discussed why Office 2010 doesn’t work with Oracle WebCenter Collaboration Server, how it can be patched, and even the enigmatic post about Office 2010 document formats.  So we know that Office 2010 WebDAV can work with Collab.  But even though the Apache/AJP hack fixes WebEdit for Office 2010, unfortunately it breaks something else.  Specifically, when you close a document that you’re “Web-Editing”, Office 2010 sends the file back to Collab, and it doesn’t seem to include a Content-Type header (damn headers…).

Because Collab isn’t told what the Content Type is, it has to guess, and as mentioned, the Office 2010 document format is a .zip file that contains XML.  What ends up happening is that, after a successful WebEdit operation, if you try a simple download of that document in the portal, you get a .zip file with all those .xml docs in there.  This threw me off for a bit, thinking that the original document was lost to this crazy .xml file.  But, once I realized that renaming the file to .docx and opening in Word 2010 still worked, it was clear the problem was with the MIME type of the document, not the bits themselves.

This is good news – it means that Collab’s not really broken, but Office 2010 is sending the wrong Content Type when the document is closed (strangely, this happens when the doc is closed, not when it’s saved), and Collab is recording that Content Type to its CSFILES table in the database.  Specifically, the ContentType field in the CSFILES gets set to text/xml; charset=”utf-8″:

 

The best fix (hack?) I’ve found here is to create a trigger on this table to cancel out any changes that set this content type to that value.  In other words, the MS SQL trigger looks for the value of “text/xml; charset=”utf-8″” during and update, and if it’s there, the trigger rolls back the value to the original value.  As usual, proceed at your own risk, and while I can’t foresee any problems – even when uploading XML files to Collab, which are likely to have a different Content Type – this is a high-risk DB update that Oracle definitely won’t support.

(more…)

Microsoft Office 2010 (.docx) files are .zip files

Wednesday, March 16th, 2011

Sit back and let me rap atchya, slinging some factasms about the Office 2010 document format (.docx, .xlsx, .pptx).

You’ve no doubt been using Office 2010 for a while and saving files with those new formats that don’t work in Office 2007.  Those .docx, .xlsx, and .pptx files are part of the Office Open XML file format.  What you may not know is that they’re actually ZIP files.  Really – try taking any .docx file you’ve got and adding .zip to the end – it’s a .zip file:

Who knew, huh?  More importantly, what’s this post doing on a Plumtree bog?

If you’re planning on using WebEdit with WCI Collaboration and Office 2010, it’s a very important nuance, because yesterday’s Collaboration WebEdit Hack isn’t going to be practical without this nugget of knowledge.

A fix for WCI Collaboration WebEdit using Office 2010

Tuesday, March 15th, 2011

As we saw a couple days ago, WebCenter Collaboration Server doesn’t work with Office 2010. The problem is rooted in the fact that WebDAV calls to Collab from Office 2010 aren’t strictly RFC-compliant because they’re missing a Content-Length header, and Tomcat rejects them because of that – even before Collab gets the HTTP requests.

Which got me to thinking: what if we could create an intermediate server that would add this header for us?   Then Tomcat would accept the connection and we’d be able to tell if Collab was able to “do its thing”. I started down the path of creating an Apache ProxyPass to do just this, when a friend and fellow Hak’er (Brian Hak) – who has been fighting his own fires with Collab these days – suggested that I try AJP. Even better, he pointed out, Collab’s default configuration settings allow you to turn this on by just flipping a switch; with it, we could then use mod_headers to add the Content-Length header.

Tip o’ the the hat to Brian for the AJP idea – it turns out that if Apache and AJP are handling the HTTP requests rather than Tomcat and its embedded web server, we don’t even need to muck with HTTP headers, as the request does NOT get blocked:

… and WebEdit (mostly) works in Office 2010!

I should warn you before proceeding: While I can absolutely say that WebEdit works in my test environment with Office 2010, .NET WCI Portal 10.3.0, on IIS 6, your mileage may vary, and I can’t guarantee this will work. I’ve found that Office 2007 has its own quirks – it works with the Collab Office Tools plugin in the ribbon bar, but not the out-of-the-box “save” implementation using Office’s own WebDAV calls. Perhaps that’s a post for another day, but early results show that while this hack doesn’t hurt Office 2007 support, it doesn’t seem to help either. Obviously, do extensive testing before even considering moving to a production environment.  Stay tuned for the next update in these pages, as there’s yet another database hack needed to make it fully functional.

Disclaimers out of the way, let’s dig in. Basically, what we’re going to do is:

  1. Install Apache Web Server on the Collab Machine, with the AJP plugin
  2. Configure Collab to accept AJP calls
  3. Configure the portal to send requests to Apache instead of directly to Collab (Tomcat)

(more…)

WCI Collaboration Server Not Working in Office 2010

Tuesday, March 15th, 2011

I’ve blogged a LOT about Collaboration Server, and have spent countless hours fighting with the WebEdit features – it’s the “bane of my existence“, a term I used because I thought “crime against humanity” was a little too strong.  More often than not I’ve thrown up my hands and said “sorry, fella, nothing to see here – it just plain don’t work”.  The problem is there are a near-infinite number of combinations, between the different versions of:

  • Plumtree / ALUI / WebCenter Interaction Portal (6.1, 6.5, 10.3.0, 10.3.0.1, 10.3/Neo)
  • Collaboration Server (4.2, 4.5, 10.3.0, 10.3.0.1, 10.3/Neo)
  • Windows (XP, Vista, 7), plus various patches
  • Office (2003, 2007, 2010), plus various patches
  • Application Servers (IIS, WebLogic, Tomcat)
  • Web Browsers (IE7 and IE8 – good luck if you have IE9, FireFox or Chrome)

Officially, Oracle only supports the following for WebEdit with version 10.3.0.1 – the latest publicly available version: MS Office 2003 on Windows XP SP2; MS Office 2007 on Windows XP SP2. No Office 2010, no Windows 7. Even Office 2007 is patchy at best.

I’d heard enough complaints, and decided to dig in and try to figure out why one very specific combination doesn’t work: Office 2010 running on Windows 7 against an IIS 6 .NET portal running WebCenter Collaboration 10.3.0.  Here’s what the out-of-the-box install shows when trying to save a file opened through WebDAV:

Your changes were saved but could not be uploaded because of an error.  You may be able to upload this file using the server Web page.

Having not accepted that it was impossible to get WebDAV working in Office 2010, I’ve spent countless hours reverse-engineering Office’s WebDAV protocol, WebCenter Interaction gateway calls, Apache Tomcat protocol handling, and everything in between.

Based on my research, this hack may be helpful for other versions of Office, Windows, and Collab, but I can’t even guarantee the hack I’ll discuss in the next couple of days is perfect, even with these very specific versions.  Proceed at your own risk, and drop me a line if you’d like to discuss your specific situation.

(more…)

Try non-gatewayed WebEdit for better Collaboration WebDAV access

Sunday, March 13th, 2011

Last month, I posted a patch for the unsigned applets in WebCenter Collaboration Server. At the time, I said:

When your users click on the “More Information” link, you’ll see a message about Integryst asserting that the application is safe. That is true. But you’ll never hear me asserting that the application doesn’t suck.

That may have been a bit of an unfair jab – Plumtree Collaboration Server was a decent product in general, so let me refine the jab: as it evolved to ALUI Collaboration Server it remained a decent product that got the job done, even while showing its age as the years marched by. But WebDAV / WebEdit access in WebCenter Interaction is a complete mess – unless your end users are still using Windows XP and Office 2003. If they are, you’re in luck! The functionality merely “sucks”, which is much better than what I can say for your more modern users with Vista or Windows 7 using Office 2007 or Office 2010.

This tip is a simple and documented one: if all your users are on the corporate intranet and can directly access your Collab Server, you may get better results with WebEdit if you don’t gateway the requests through the portal. Just change “nonGatewayedAccess” to “yes” – and make sure your entire user base can access that URL (i.e., you’re not running an extranet where the Collab Server is behind a firewall).

<webEdit enabled="yes">
<nonGatewayedAccess enabled="yes">
<serverURL>http://collaboration_server:11930/collab</serverURL>
</nonGatewayedAccess>
<tokenBasedAuthentication enabled="true">
<useClustering enabled="no">
<maxWaitSeconds>30</maxWaitSeconds>
</useClustering>
</tokenBasedAuthentication>
<truncateFileNames>75</truncateFileNames>
<clientControl>
<clsid>6882A029-D576-45FC-B966-7288891BDF58</clsid>
<fileSpec>PTWebEditControl.CAB#version=1,0,0,0</fileSpec>
</clientControl>
<installOfficeToolsPopUp enabled="yes"/>
</webEdit>

Stay tuned for some even bigger news in a future post; with some extensive reverse-engineering of Microsoft Office’s WebDAV protocol implementation and Apache Tomcat’s HTTP implementation, I’ve gotten WebEdit and WebDAV working for Office 2010 on Windows 7. There are some side effects that I’m working through as we do some regression testing but I’m pretty confident we’ll have a solution ready soon for using Collab WebDAV with modern versions of Windows and Office. Drop us a line if you’d be interested in testing out the solution.