Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Even when logged in correctly, clicking on a link to a blog (?) from a different source such as a Word doc generates a Forbidden fail page.
Needs further explanation from Cerys / Colin.
We can't replicate this.
Cerys, can you show Andy or Justin next time you are in.
If a link to a blog post has been created in a different source, for example in a Word file, PDF, or web page, a user the user is logged onto the blog and has to security access to the the blog post may get Forbidden message when they click the link. This behaviour is intermittent and probably relates to other examples of behaviour where Forbidden is displayed when the user is logged on, but for some reason the request is denied.
So to reproduce:
Write a word doc with two or three links
First to a BBC website news article
Second to a LabTrove blog post that is only accessible to an authenticated user.
[Third to a googledoc that is only accessible to an authenticated user].
Log out of LabTrove. [Log out of google].
Close all browsers.
Click on the BBC link - it should load in a browser
Click on the LabTrove link - it should give an authentication challenge / forbidden
Click on the Googledoc link - should get an authentication challenge.
Close the .DOC
Close all browers
Log into googledoc in a fresh browser.
Open the .DOC
click on the googledoc - should open the doc in a browser tab/new window.
close the browser
Close the .DOC
Log into the LabTrove blog with the same ID that can see the linked blog post.
Open the .DOC
click on the link to the blog post - should display in the browser.
Fix for 2.2 but only if we can reproduce reliably.
Andy, fix this if you can understand the problem.
Confirmed with Word for Mac / Safari
Win 7 with Firefox *or* IE9 as default browsers. Word doc with link:
All browsers closed. Blog viewable only by logged in.
Link click bounced to (no messages) to http://vm05.omii.ac.uk/jsr/
184.108.40.206 - - [01/Nov/2012:16:30:20 +0000] "GET /jsr/qwertys_blog/88/Testing_all_those_lovely_Combo_boxes.html HTTP/1.1" 302 450 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; ms-office)"
220.127.116.11 - - [01/Nov/2012:16:30:20 +0000] "GET /jsr/ HTTP/1.1" 200 2269 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3; ms-office)"
18.104.22.168 - - [01/Nov/2012:16:30:21 +0000] "GET /jsr/ HTTP/1.1" 200 2199 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0"
It transpires that clicking a link in MS-Office doesn't, in fact invoke the default browser with the requested URI, but instead opens the link itself using it's internal browser engine, and hands off the response to your default browser.
The two browser engines don't share cookies, so the user is authenticated.
Good work tracking this down but I don't think it's closed yet.
I agree that it isn't our problem and there is nothing that we can fix.
This phenomenon should be written up in the doc somewhere,
maybe FAQ's or Troubleshooting so that the knowledge is propagated.
And is this solely an Office issue or does it happen with PDF's or other document formats too? (I don't think so)
Opening links from a PDF document with Adobe Reader XI behaves as expected: Opens in default browser preserving any open session.
In which case I think we should just document Office Documents' behaviour as an anomaly and leave it.
Out of interest, which versions of Word(Office) did you try this with.
It could be that later editions (like 2010) do something different.
Office tests were carried out using
MS Office 2010 Professional Plus 2010 Product Version 14.0.4763.1000
on Windows 7 Enterprise 64 bit
Known issue (With MS)