Is there an update on this issue?   The registry fix is impractical and doesn't appear to work on later versions of Office (e.g. 2013)

Is there a workaround for Mac users as well?

RE: "The third-party applications that have been involved in reported cases include:
◾MS Outlook
◾MS OneNote
◾MS Word"

This also happens with MS Excel - when clicking on a link from a list of issues which has been exported from Jira.

I'm re-opening, because the client-side registry workaround is not suitable in many cases.

To summarise the underlying problem: when a user pastes a link to a JIRA OD issue or a Confluence OD page into an MS Office app, the Office app uses an unauthenticated session to follow the link behind the scenes. Being unauthenticated, it gets a redirect to the login page, and it updates the pasted link to point to that login page. Therefore, users who click the link in the Office app go to the login screen instead of the original resource, regardless of whether they are authenticated. There is a registry patch to change this behaviour in Office, but applying that fix is not practical/possible for many customers. There's more info from MS here.

This still is not fixed.

When will this fix be deployed?

This issue relates to
JST-82496

Hey Robin,

I work in an organization that has 1900 users on Confluence so I don't know how we could have this workaround applied to each of their computers individually. Whenever we send out internal communications, we link directly to the file for the user to download it. Is there going to be a fix on the Confluence side that would address this? Would this still be an issue in the local version if we were to purchase that?

This will become a more urgent issue as our organization has adopted Confluence for all of our internal wiki needs, replacing some other systems. This is one function that we absolutely need to work though so we can share files with people all over the world.

Thanks,
Dave

Hi Dave, the status of this issue is perhaps a bit misleading. The fix for this problem is available now; it must be applied on the user's side by following Microsoft's recommended registry change, as described in the comments above.

Hope that helps!
Robin

Hi all – very happy to see this is getting fixed as I've been receiving a lot of questions about why this isn't working from the whole organization.

Do you have a rough timeline on when this update will be released?

Thanks,
Dave

There are some interesting workaround notes in this Answers post.

Resolving: responses from support cases suggest the registry edit workaround is suitable for affected customers.

Note that if you'd rather not edit the registry manually, Microsoft provides a "Fix it for me" executable download in this article.

Confirmed that with the registry change in place, no requests emanate from the office apps: they are handed over to IE immediately. This should prevent the redirection to the login page, and could therefore be a suitable workaround for customers suffering from this problem.

The registry change consists of setting or creating a DWORD key ForceShellExecute with value 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\9.0\Common\Internet.

I have set up a WinXP VM to experiment with links from Office (Word and OneNote) to an OD instance for which I have an active, authenticated session in IE8. I'm monitoring the requests in a debugging proxy.

I have seen a small number of unexpected login prompts when following such links, but I haven't yet found a consistent way of reproducing the problem. Usually the links work fine.

Even in the working case, the sequence of requests that occur when clicking on a link from OneNote are interesting:

#	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
50	200	HTTP	Tunnel to	robinf25.jira-dev.com:443	0			onenote:3248			
51	302	HTTPS	robinf25.jira-dev.com	/browse/DEMO-5	20	no-cache, no-store, must-revalidate  Expires: Thu, 01 Jan 1970 00:00:00 GMT	text/html;charset=UTF-8	onenote:3248			
52	302	HTTPS	robinf25.jira-dev.com	/login.jsp?permissionViolation=true&os_destination=%2Fbrowse%2FDEMO-5	154		text/html	onenote:3248			
53	200	HTTPS	robinf25.jira-dev.com	/login?dest-url=%2Fbrowse%2FDEMO-5&permission-violation=true	2,224		text/html; charset=utf-8	onenote:3248			

54	200	HTTP	Tunnel to	robinf25.jira-dev.com:443	0			iexplore:3572			
55	303	HTTPS	robinf25.jira-dev.com	/login?dest-url=%2Fbrowse%2FDEMO-5&permission-violation=true	0			iexplore:3572			
56	200	HTTPS	robinf25.jira-dev.com	/browse/DEMO-5	12,538	no-cache, no-store, must-revalidate  Expires: Thu, 01 Jan 1970 00:00:00 GMT	text/html;charset=UTF-8	iexplore:3572			

Requests 50-53 are issued from OneNote, and 54-56 from IE. Notice that OneNote initially tries to follow the link, but because it is not authenticated, it gets redirected to the login prompt. So it is the link to the login prompt that is passed to IE. Then, in the working case, IE immediately gets redirected to the intended target page because IE does have an authenticated session.

As fcuozzo pointed out in JST-48442, it's likely that what we're seeing is a consequence of Office apps attempting to create a second session.

Microsoft do provide a registry hack to circumvent the problem, but I'm not sure why it should be necessary: what's unclear to me is why, under some as-of-yet unknown circumstances, the login page does not redirect to the target, even though there is a valid session in IE.

Looks similar to https://jira.atlassian.com/browse/AOD-6051