Posts Tagged ‘authentication’

LinkedIn has recently made modifications to their authentication system requiring users to re-authenticate every 60 days.  Expiring access in this way is generally done to circumvent situations where a 3rd party was granted permission long ago and you haven’t gotten around to barring them access to your data.

To re-authenticate, click “Settings” on your LinkedIn feed, then select your authentication method as pictured here.  (the email option is typically intended be used only for getting a link to someone who does not have access to CloudPreservation)


As the feed’s owner, you will be notified again when the authorization period is expiring.  Failure to (re)grant that permission will result in CloudPreservation no longer being able to obtain/capture your data from LinkedIn. As always, the actual authentication involves CloudPreservation sending you to a LinkedIn server to provide your credentials and grant the permission.  CloudPreservation will never obtain or store your personal LinkedIn password.

Read Full Post »

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.

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 »