Feeds:
Posts
Comments

Archive for December, 2009

We bumped into an interesting issue the other day involving links from Microsoft Word to documents stored on the Nextpoint web applications. A perfectly valid link would take the user not to the document they desired but to our login page, despite already having authenticated.

What’s the deal? Microsoft Word is trying to help you out by checking if the thing you’re linking to supports “Web authoring and collaboration.” It makes the request for you behind the scenes to see where you’re headed. Our site (of course) tells Word “you are not authorized” – because it isn’t – and redirects it to the login page, just like anyone else who tried to request something before logging in.

The part that we don’t like is that instead of Word taking this result as “I can’t help you, so I’m just going to let you go where you requested”, it says “looks like your URL redirects elsewhere” — so it sends you directly there (the login page) instead of to the original URL. (more here: support.microsoft)

Real. Nice.

Luckily, all you have to do to resolve the issue is have every user of your service make some registry changes… you know… cuz that’s practical.  And easy for Mac users, too.

If this issue occurs when you click hyperlinks in Office documents that either directly open HTML Web content or are redirected to HTML content, client users can avoid the problem by enabling a registry key to send the hyperlink navigation to the browser instead of directly binding to the hyperlink from Office.
support.microsoft

How we’re dealing with it

As you may have already guessed, “looks like MSFT made some interesting implementation decisions” isn’t an answer that we’re comfortable giving.

We immediately threw out a couple of potential solutions – one involved putting the requested URL in the query string of the login page redirect, so when we see “hey, you (1) requested the login screen even though you’re authenticated and (2) you have this special parameter,” we could send you to the proper doc.

I think that would have worked just fine, but we went with Door #2: rendering the login page inline for specific document requests, if you are not authenticated.  We have a whitelist of which requests allow this behavior.

When Word sees this it thinks (1) Oh, looks like these guys aren’t using some crazy proprietary document editing system on the web and (2) No redirects happened, so I’ll just send the Word user to this URL (you know… the one they told me they wanted).

Had Word been paying attention, it would have seen that this is a login page – but it doesn’t care about such things. When it sends you there (in your browser which actually is authorized) you get the regular document instead of the login page.

We like the solution, it solves the problem and (normally) prevents funny query strings from needing to be passed around. The downside is that we’ll need to maintain that whitelist, but we feel like we’ll be able to keep on top of that pretty well.

Read Full Post »

When faced with a stack of paper, it’s easy to grab a marker and black something out (even if it doesn’t always work out quite as intended).  Our Discovery Cloud offering (available publicly last month) aims to make the process even simpler, faster, and cleaner – and certainly not as permanent.

Click "Redact"

Along with blocking out the the images, we also reprocess (OCR) the image to ensure that the underlying text will never be exported +/- appear in our search indexes.

Make a mistake or get word that one of your redactions is not allowed?  Unredact any individual redaction you’ve made (if you made “multiple passes”) or revert the whole doc (if sufficient auth-level).

Read Full Post »