Hi there,
I noticed documents which were uploaded in the Press Library (OMP) or the Publisher Library (OJS 3.0) can be seen if you know the url, therefor they aren’t protected (unlike the Files Browser in the older OJS-versions). Is this intentional (a feature) or a bug?
Will this change in the future or can we use it to provide users with author guidelines (für example)?
Kind regards
Daniela
Hi @UBWolf,
These aren’t intended to be protected – it’s a general storage area for press-related documents, which we hadn’t considered to be private. If you’re concerned about access to these documents, could you describe how you intended to use that feature?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher
we were discussing about storaging our author’s contracts in the system, but it’s obviously not the right place for that 
I have another question though: After deleting an item in the library the file is still on the server, which makes sense. But why does the entry in the library_files-table remain in the database? Is it still referenced somewhere?
Kind regards
Daniela
Hi @UBWolf,
There’s the Press/Journal Library, where blank templates should be kept – these documents shouldn’t be private. And within each submission there’s an opportunity to upload documents, e.g. filled-in contracts, which should be private to press/journal staff. Does that make sense?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
then something must be wrong. The files are uploaded into /files/contexts/PRESSID/library regardless of uploading it into the press or the submission library. And I can always access them if I enter WEBADRESS/files/contexts/PRESSID/library/FILE. It doesn’t matter if I’m logged in or not.
Kind regards
Daniela
Hi @UBWolf
It seems that your files folder is under your web or OJS root i.e. publicly accessible? If so, this must not be the case, for security reasons, s. also ojs/README at ojs-stable-2_4_8 · pkp/ojs · GitHub…
Best,
Bozana
Thank you for your explanations! But there is one thing I don’t understand: wouldn’t it be better for security reasons if the files which should be avaible publicly were in a different folder than the ones which should be protected?
Kind regards
Daniela
Hi @UBWolf
Currently it is so, as you say – there is the public folder where all the public files go (e.g. journal and cover images) and files folder where all other files go. Those other files in the files folder can also be publicly accessed (e.g. galley files) but securely via OJS i.e. not directly – system is in between and delivers the files to the user as needed. This way it is not possible to execute malicious files on the server. Thus, for the future, we are considering using the same mechanism for all the files i.e. protecting all the files in that way, also those currently in the public folder.
Best
Bozana
I have a somewhat reverse question: how do you get the URLs of those files in the Publisher Library, to make them publicly accessible (e.g. to insert them into the About field)?
@Ph_We
I have browsed the directory on the server to find the files. This is the url I got:
http://DOMAIN/ojs/files/contexts/JOURNALID/library/FILENAME
But as @bozana said, this isn’t a good installation and the files folder should be somewhere else. So far we are only testing and I’m sure our IT department will do things differently once we go productive.
Kind regards
Daniela
Thank you!
Would it be safe to give the journal managers such URLs, so they could use them to share the PDFs with readers? Is there any chance those URLs might change with some upgrade of OJS?
I mean those ‘direct’ URLs to PDFs, @UBWolf talked about, like
http://DOMAIN/ojs/files/contexts/JOURNALID/library/FILENAME.pdf
Users have a lot of such PDFs (like instructions to authors, different kinds of contracts, etc.), which they would like to display on their main pages.
The URL UBWolf provided was OJS files folder, that was in the webroot. That is not secure!
At the moment there is only the possibility for web admin to manually upload those PDFs e.g. in the OJS public folder (you could eventually create a new directory (e.g. “download” or so) in the public folder and upload the PDFs there). They would then be accessible by everyone. It is a little bit manual work, but… till the right solution comes… ?
sorry for brining this up again after this time, but I don’t understand, why the files still remain on the server, when they are deleted in the backend. Could you please give me an explanation for that? [up to now: OJS3.0.2]
And we use this Publisher’s Library for all materials like author instructions etc. But our files dir is outside the root, but I managed to put a symlink »downloads« into root, which points to the protected library folder. Is this a secure approach?
Thanks
Tobias
Hi @twa
What do you exactly mean with “the files still remain on the server, when they are deleted in the backend”? What files do you delete and how?
What is the content of your folder “downloads”? Is that folder manually created? How are the documents uploaded there? Could you also put the “downloads” folder into the folder public? – just to understand…
Best,
Bozana
as far as we found out
Settings > Workflow Settings > Publisher Library
is the only place in OJS3, where we could upload files to the webserver from inside the system itself.
Files uploaded here are physically stored into
/files/context/[journal-id]/library
on the webserver.
The files folder lays outside the web root, so it is inaccessible from the web. Now we created a symbolic link on webserver’s root
www.ourjournal.xyz/downloads
which points to
/files/context/[journal-id]/library
so we could upload, and set links to www.ourjournal.xyz/downloads – all inside OJS.
So physically there is no download folder, only a symlink.
With making a download folder inside public, we need to upload files via FTP, which we like to avoid.
So when I delete a file inside OJS in
Settings > Workflow Settings > Publisher Library
it stays physically on the webserver in
/files/context/[journal-id]/library
– why is this so?
The best would be a upload area inside OJS, where editors could put (Word, OOO, PDF, etc.) files in as author guidelines, review templates, word templates, call for papers etc.
Thanks,
Tobias
Hi @twa
Aaaaa… Now I understand
I believe your solution with sym link is secure, if nobody else can upload any malicious file to that download folder and also to the publisher library – right @asmecher?
Hmmm… I will take a look why those files are not deleted (within the recent OJS release) – it could be a bug…
Yes, we are planing to solve that document (e.g. template) upload problem,…
Best,
Bozana