Redesigned Dashboard & Workflow - Persisting state in URL

[jardakotesovec]

To make it easier to bookmark and share urls in dashboard and workflow, following items are being persisted to the URL as query params.

This is new feature compared to 3.4.

• selected view in dashboard
• selected filters in dashboard
• search phrase in dashboard
• which column to sort by in dashboard
• opened submission id in workflow
• selected menu in workflow

Testing is mostly just copying url and making sure that the state was applied accurately.

[Tribunal33]

@jardakotesovec One possible efficiency (I don't know what to call it) would be if the user has opened up a workflow pane the search Phrase shouldn't be kept since it doesn't do anything when you copy and paste the urls for state?

Here is an example with searchPhrase being kept in the URL but the workflow is opened and the search doesn't have anything to do with it.
/ojs-main/ojs/index.php/publicknowledge/en/dashboard/editorial?currentViewId=active&sectionIds=1&daysInactive=16&searchPhrase=learning+trends&workflowSubmissionId=11&workflowMenuKey=publication_jats

It also introduces a bit of a security flaw in that I can send you a link with a searchPhrase that could potentially allow a user to put malicious code into the string.
Something like this doesn't work but you get the idea :) :
/ojs-main/ojs/index.php/publicknowledge/en/dashboard/editorial?currentViewId=active&sectionIds=1&daysInactive=16&searchPhrase=<script>alert('work')</script>&workflowSubmissionId=11&workflowMenuKey=publication_jats

This is more of a generalized method for all parameters but I'm thinking about this : https://pragmaticwebsecurity.com/articles/apisecurity/tamper-proof-params-jwt#:~:text=URL%20parameters%20are%20present%20in,a%20URL%20containing%20sensitive%20parameters.

[jardakotesovec]

@Tribunal33 regarding the search phrase. That still gets applied, but to the dashboard state, not workflow as all other filters. I don't think thats causing any problems? Even if someone is sharing url with opened workflow page - keeping the dashboard state increase the chance that after closing workflow page - that particular submission will be somewhere in that listing.

Regarding the xss attacks, these are prevented (escaped) on rendering layer (vue.js), so we don't do any explicit handling of that.

[Tribunal33]

@jardakotesovec this case passes QA. The tricky part was trying to figure out how these URLs interact with certain users. Which users are able to see what. I did not see requirements on them so I tried a few that I knew shouldn't be allow. It blocks them correctly -- gives this error response index.php/publicknowledge/en/user/authorizationDenied?message=user.authorization.roleBasedAccessDenied

These params are easy to manipulate because of the readability but if the search bar is escaping properly then I don't really see a strong attack vector here. Might be something to monitor on hosting side to scan for any malicious looking urls.

@pmangahis I believe that PS team wanted to make sure copy pasting urls was working well. Are there any other cases I might have missed?

Test Case Overview

1. Test each of the states by copying to incognito browser tab
   a. The view
   b. The filters
   c. Search phrases
   d. Column sorting
   e. Opened submission id
   f. Selected side menu in submission workflow
2. Reverse the param states beginning with full params in the URL
   a. Close the submission
   b. Clear filters
   c. Cancel search
3. Test user access to these URLs
   a. Author shouldn’t have Access to wrong submission ids
   b. Readers shouldn’t have access to certain views