OJS integration: By creating a new revision by submitting article after photos and bibliography are not copied

[afshinsadeghi]

This can be due to:
Author is Owner but after the change of the version, he is not the owner of the document.

[johanneswilm]

The problem is mainly due to the following combination of circumstances (pssibly in addition to a bug):

• The hand over of a document from the original author to the administrator of the journal is done through the savecopy method.
• The savecopy method goes through the document that is to be copied and looks for images and citations. It then compares these with the bibliography and image databases of the owner of the new document.
• In order to do the comparison, savecopy needs the image and bibliography databases of the owner of the new document.
• For security reasons, a user is only allowed to download the bibliography or image database for another user if that other user shares at least one document with the user in question.
• The user submitting a journal article will usually not have access to a single document shared by the journal administration user, so the user will not be allowed to download those databases for teh copying.

Possible solutions

1. Move the copying process of the document from the end user to the journal administrator. The click on the submission button will then be a special kind of sharing of the document.

Con: If an article author submits a document to a journal, and then subsequently makes changes to it before the journal administrator manages to start the copying process, the changed version will be used in the peer-review process. This is likely not what the author expected.

2. Use a modified version of the revision saving and restoring process. The revision saving process takes the document, looks through it for all citations and images and creates minidatabases that only contain the images and citation soruces that are used in the document in question. It then creates zip file of the databases and the document contents (fidus file) and stores it on the server. The revision-restore process downloads the zip file from server to browser, unpacks the zip-file and imports the mini-bibliography and and mini-image databases into the databases of the current user.

Pro: Will make an exact copy of the doc at the time of submission, and will simultaneously not give the article author access to the image/bib databases of the journal administrators.

3. Create "special admin users" for journals for which the security works differently.

Pro: Connecting journals to specific "journal admin" users registered for each journal will likely have to be done anyway in the long run, so this will likely have to be added to the code anyway. Right now the user with id==1 is treated as a type of universal admin user who gets all user rights for submitted journals. That is not very scalable.

Con: This could lead to big security issues where a user can get access to the media of citations of other users by submitting an empty article to a given journal.

[johanneswilm]

Hey @sadeghiafshin,

I have been working on this on the FW side. Some questions in that regard:

• I see we are sending a form from FW to OJS. Is there a particular reason we are sending a form rather than an ajax object?

• I see we are not (always) sending the key for request to OJS. I have added some code to always send the key as well.

• We have a complex rights problem on the FW side. Would it be possible to have the journal editor open a page on FW before assigning the document to editors?

[afshinsadeghi]

Sorry for the late comment @johanneswilm.

1. That is to become compatible with the other side.

2. Good point, I have already made an issue for that here: secure OJS and editor transactions using shared key OJS-Authoring-Integration-plugin#16

3. Is MIT license compatible with FW?

[johanneswilm]

3. Yes, MIT is compatible both with OJS and FW.

But in this connection I didn't mean the license of the code. I meant this:

Basically there is a problem with access rights. If the end user can upload their pictured directly to the admin user, they can also see all the existing images of the admin user. This is problematic if the admin user also receives the pictures/citations of everyone else.

So instead I will let the end user just upload a fidus file to the server as part of the submission. The admin user for the journal then needs to unpack that file first. This should work, but what if the admin user directly appoints reviewers who enter the document before the admin has been at fidus writer to unpack it?

So what I came up with is this: Instead of going directly to a document, OJS gets a URL for the submission at FW such as /ojs/submission/371. If a user arrives at Fidus Writer with the correct api_key at that url and the doc has been unpacked, the user is logged in as whatever user that is (admin or reviewer) and then redirected to the doc. If the document does not yet exist, the client is first logged in as an admin user and sent to a page which unpacks the submission into a doc. Then the user is logged out again from the admin account and into the reviewer account and then forwarded to the URL of the doc.

The security problem is now much smaller: Only a reviewer user could during the seconds that he is logged in as the admin user stop the JS, and change the URL to the regular document overview page and would be logged in as the admin user. This is not perfect, but it only concerns reviewer users under fairly special circumstances.