-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[issue_tracker] Add attachments to issues #5394
[issue_tracker] Add attachments to issues #5394
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry to ask for this but I think pretty much all of the PHP will need to be redone. Let me know if you have any questions about the points below.
-
File uploading is a complicated feature and is hard to get right from a security perspective. From what I can see here there are no protections against path manipulation so this code introduces a vulnerability into the codebase.
-
New file uploading code should use the class created in my recent PR [Core] Create File Uploader class to standardize and validate file uploads in LORIS . There is an example of usage there. See also https://github.com/aces/Loris/pull/5234/files
-
This PR is also using non-standard DB operations (I think copied from genomic browser if I'm not mistaken). This isn't advised (genomic browser needs updating).
Additionally:
- I don't think there's any purpose in using cryptographically unique identifiers here. Regular MySQL IDs are just fine.
- Related: we don't need a new openssl dependency for generating secure random numbers. The code example you've used is four years old.
random_int()
is fine for such things. - You've committed two ZIP files that should be removed (I'd advise against using
git add -A
) - All new functions need type hints; new PHP files should declare strict types
I'd recommend refactoring the Issue Tracker to use Request and Response Interfaces in the newer style and from there making use of the new File Uploader class I linked.
Hey @johnsaigle the reason I went with the code I did was because the issue_tracker module does need to be refactored. I thought it would be best to add the features before that task or it would make the task much bigger. I'm not sure how path manipulation would happen with this PR but I didn't see permission checks for the EditIssue.php and just used that as a template for the Attachment.php. I think refactoring after would be best for splitting the task into more easily reviewed PRs. |
It's a reasonably-sized task but I think it makes sense to implement the Response/Request interfaces first so that you can use the File Upload class. I think this is better than adding more onto something that should be redone anyway. The security of it goes beyond permission checks. You can look into some merged PRs labelled with "Security" if you want some background. You've brought up UUIDs before (discussion begins here). I think the points from that thread still stand. |
@johnsaigle I spoke with @ridz1208 before writing the code. I even mentioned that PR in the discussion. I think there is a benefit and that I want to discuss at the Loris meeting. |
For sure we can discuss it further there. Regardless of the UUID portion, I still think a lot of this will need to be refactored. In the case that the UUID part continues, you'll need to update and commit the composer.lock file. It would also be good to use a specific version of the SSL dependency. |
Adding Needs Work due to the following points from my above review:
These need to be fixed. Everything else will be decided by further discussion. |
feature change -> requires updates to module spec markdown and also Help text. |
d52c067
to
47805eb
Compare
This has been discussed in a LORIS meeting as of Dec. 10. The PR is now in @driusan's court to review. |
I'm having issues manually testing this. |
74216f1
to
43bdf01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hopefully one last minor change..
Hi @driusan, all requested changes have been added to the PR. |
Hi @driusan, all the baseURL requested change has been added to the PR. |
Co-Authored-By: Dave MacFarlane <[email protected]>
Thanks @driusan updated |
This needs Travis to run on it to be merged |
@driusan how do I get travis to start again. I'm wondering if it's a GitHub issue. |
No idea, all I know is that there's not even a yellow checkmark on the last 2 commits. Sometimes that means there was a GitHub hicup that can be fixed by closing and re-opening the PR, sometimes that means there's a conflict or misformed |
@driusan resurrection of travis happened after closing & reopening. |
Brief summary of changes
Testing instructions (if applicable)