Open afshinsadeghi opened 7 years ago
The problem is mainly due to the following combination of circumstances (pssibly in addition to a bug):
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.
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.
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.
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.
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?
Sorry for the late comment @johanneswilm.
That is to become compatible with the other side.
Good point, I have already made an issue for that here: https://github.com/OSCOSS/OJSIntegrationRestAPIplugin/issues/16
Is MIT license compatible with 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.
This can be due to: Author is Owner but after the change of the version, he is not the owner of the document.