pdf viewer does not work when a folder is shared via a URL

[xoomtalk]

When a folder is shared via a URL to a external entity, the embedded pdf viewer does not work.
The same folder when a user is logged into the webclient displays correctly in the pdfviewer.

However if the folder is shared via a URL the pdfviewer doe not display the pdf.
The image viewer and the odt client are both working correctly.

Regards

[cyhlau]

Same here.
I am using OC 5.0.6, which is the latest version at the moment.
And I still experience this issue.

This is a post 6 months ago.
I would like to know is there a fix now?

[ghost]

Hi,

I too would like to see this feature included in pdf viewer. Would be great if the developers could look into it :)

Thanks

[torbennehmer]

Fixing this problem would help me a great deal as well.

[dinobert]

Yes! That would be great!
It's one of two reasons why I still have to use Dropbox!
(The other one is that there is no slide show possible in shared folders.)

[RandolfCarter]

On the other hand, e.g. firefox opens all linked pdf files automatically for viewing using pdf.js - and also for other browsers there's plenty of plugins to display pdf files; so in my opinion the built-in ownCloud pdf-viewer is a nice gimmick, but not really necessary. Is it really that much of a hassle to require users to click the download button?

[alexeyvolkoff]

I think it's not right to rely on user's software if some functionality misbehaves.
Besides, unnecessary downloads increase "data entropy" which this software is aimed to combat.

The similar problem exists also with TXT viewer on public link. The empty document is displayed until you log in. So the problem is serious.

PS. there is also a design mismatch - PDF content frame is displayed under the footer.

[torbennehmer]

FF (and other browsers) normally do open the PDF file as Plugin in the browser, but - and that's the key point here - the downloads delivered by owncloud include the Content-Disposition: Attachment (or something close to that) header in the download, which forces the browser to download it. Which is quite annoying.

[midoriatlantica]

Update apps/files_pdfviewer/js/loader.js changing line 18 to following code and its work now.

if ($('#isPublic').val()){
var url = '/Shared/'+$('#filename').val();
var viewer = OC.linkTo('files_pdfviewer', 'viewer.php')+'?dir='+encodeURIComponent(url).replace(/%2F/, '/')+'&file='+encodeURIComponent(filename.replace('&', '%26'));
}
else {
var viewer = OC.linkTo('files_pdfviewer', 'viewer.php')+'?dir='+encodeURIComponent(dir).replace(/%2F/, '/')+'&file='+encodeURIComponent(filename.replace('&', '%26'));
}

If you want the shared folder is accessible without logging comment line 3 apps file / files_pdfviewer / viewer.php

/ / OCP \ User :: checkLoggedIn ();

Add a user account with read-only permission and download and add the following line in the file viewer.php

if ($ _GET ['IsPublic']) {
$ _SESSION ['User_id'] = 'midori';
}

[andrewleith]

@midoriatlantica can you be a little more clear in your steps to fix this? I tried what you said on owncloud 5.0.13 (as best as i could follow it) and it still didnt work. It said my PDF was corrupted. Any advice?

[alexeyvolkoff]

@midoriatlantica, the same here. I still get "PDF is corrupted".
Can you please share your loader.js and viewer.php files? Or the whole app?

[PVince81]

The PDF viewer implementation doesn't know how to load public files and only works with internal files.
It was disabled in OC 6 for that reason until this is fixed.

As per the linked ticket the issue also exists in OC 5.0.13

[midoriatlantica]

The problem with the way public share , is more specifically associated with the user session . A work solution found for me solve this problem is as follows:

[apps/files_pdfviewer/viewer.php]
Remove the check authenticated user on line 2
/ / OCP \ User :: checkLoggedIn ( ) ;

After Line 6 added a check to see if there is a logged in user , if there is no attribute session user_id
for a standard system user with read-only permissions .
if($_GET['isPublic'] == 1) {
$_SESSION['user_id'] = 'username';
}

[ apps / files_sharing / templates / public.php ]
It is necessary to keep the name of the shared directory , then assign the directory name
shared to a variable of type hidden by adding the following lines after line 7

[core / js / js.js ]
Added after line 639 an ajax php script to call a function

function setSession(SessionName, SessionValue) {
$.ajax({
type: "POST",
url: "setsession.php",
data: {
"SessionName" : SessionName,
"SessionValue" : SessionValue
},
});
}

Call the function when loading the DOM
$(document).ready(function(){
if($('#isPublic').val() == 1 && ($('#dir').val() == "" || $('#dir').val() == "/")){
setSession('shareDir',$('#filename').val())
}
....

create file setsession.php in the folder where it was installed ownCloud

[apps / files_pdfviewer / js / loader.js ]
Delete the contents of lines 13 to 28 and add the content below

if($('#isPublic').val()){

if($('#dir').val() == "" || $('#dir').val() == "/"){
var url = '/Shared/'+$('#shared').val();
}
else {
var url = '/Shared/'+$('#shared').val()+$('#dir').val();
}

var viewer = OC.linkTo('files_pdfviewer', 'viewer.php')+'?dir='+encodeURIComponent(url).replace(/%2F/, '/')+'&file='+encodeURIComponent(filename.replace('&', '%26'))+'&isPublic='+$('#isPublic').val();
}
else {
var viewer = OC.linkTo('files_pdfviewer', 'viewer.php')+'?dir='+encodeURIComponent(dir).replace(/%2F/, '/')+'&file='+encodeURIComponent(filename.replace('&', '%26'));
}

[PVince81]

@midoriatlantica I think if you put the user_id into the session it is the same as authenticating as the file owner, which is a security issue! This means the viewing use would then be logged in as that user and can edit all their files.

The problem is mostly that the way to access the file contents is different in public mode, it somehow needs to go through the public API / public.php

[midoriatlantica]

PDFViewer need an authenticated user to view the file. But in case of sharing via link I think you will not have a user registered in the system will only be a guest user. In this case the only way to circumvent this problem is to create a user with only permission to download and display. For me this solution met perfectly, and I see no problem.

[PVince81]

Due to many reports of this for OC 5.0.13 I will attempt to backport the workaround to stable5.

[PVince81]

It looks like the fix has already be ported to stable5 and will appear in OC 5.0.14.

Leaving this ticket open for the proper implementation of the PDF view in public mode.

[alexeyvolkoff]

midoriatlantica, you didn't complete your post :)

What code should be added into [ apps / files_sharing / templates / public.php ] ?

[midoriatlantica]

I sent the full post, but it seems that there is a character limit.

[korud]

Please code full. i need this code.

[korud]

Can you post the code public.php?

[MorrisJobke]

@PVince81 Which fix did you mean? It doesn't work for OC6

[PVince81]

@kabum The fix should disable the PDF viewer in public mode. Do you still see it or see an iframe with a login page ?

[MorrisJobke]

@PVince81 No, it just downloads the PDF.

[alexeyvolkoff]

Yes, I confirm. PDF viewer is disabled in fresh OC v6 install. Just download works.

[PVince81]

Yes, that's the correct behavior for now (quickfix).

[alexeyvolkoff]

Any chance to see viewer in future?

[PVince81]

Yes, let's keep this issue opened as feature request to add it.
The problem currently is that every viewer must understand the difference between "normal" mode and "public" mode. Ideally there should only be one download mechanism regardless of the mode, mechanism that could be used by all viewers.

[dietmaroc]

@frank: re-enacted for Versions 5.0.13, 5.0.14a and 6.0.2
someone needs to have that fixed.

[dietmaroc]

@karlitschek : no longer reproducible in 6.0.2.4

[greavette]

Any updates on when this will be fixed. For now I've setup Chrome to automatically open PDF files once they've downloaded. Ideally I don't want the files to download at all...having the PDF open in the embedded PDF viewer like it does if we login to owncloud is what I would prefer.

[bigworm]

@dietmaroc does this mean the issue is rectified in 6.0.2.4 ?

[bigworm]

@PVince81 any update on this issue?

@midoriatlantica does your fix/hack work on OC6? any chance of posting a full guide?

[PVince81]

I didn't have time to work on this, sorry.

If anyone has an idea how to fix it, even partially, please do so.
A pull request might help as well, even if incomplete.

[bigworm]

@PVince81 somewhat related is there a way I can pass credentials in a URL as a workaround to this without having to hack the code as @midoriatlantica did?

[LukasReschke]

Hi all!

I've been working on this feature yesterday and with a little help from everyone on this thread ownCloud 7 (coming soon™) will include the PDF viewer for shared PDF files!

To get this into ownCloud 7 we need your help in testing this feature. - To do this:

1. Setup an ownCloud 7 alpha instance (http://download.owncloud.org/community/testing/owncloud-7.0.0alpha1.tar.bz2)
2. Replace the shipped files_pdfviewer with the one from https://github.com/owncloud/files_pdfviewer/archive/make-work-in-public-vie.zip

Afterwards test the following things:

• PDF viewer for logged-in users still works
• PDF viewer for single shared file works
• PDF viewer for shared directory works

If you've performed all these tests report in owncloud/files_pdfviewer#7 whether the feature works or not. If enough people have tested this functionality it will get merged in time for the upcoming ownCloud release.
(I'd especially appreciate testing from IE > 8 users as I've enabled the PDF viewer for those versions in this branch)

[LukasReschke]

Ping at everybody in this issue.

If my pull request does not get enough reviews it won't get included in ownCloud 7. If you don't want to wait another half a year you really should take those 15 minutes to test my changes ;-)

[LukasReschke]

This will be fixed with ownCloud 7.

Ref owncloud/files_pdfviewer#7