-
Notifications
You must be signed in to change notification settings - Fork 325
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
[ENG-607][ENG-787] Send redirect URL's to Akismet and validate URLs #9087
[ENG-607][ENG-787] Send redirect URL's to Akismet and validate URLs #9087
Conversation
d4d025d
to
97782a1
Compare
97782a1
to
1db904b
Compare
Looks good! |
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.
interesting approach @Johnetordoff! a few changes, and I would recommend moving the spam checking back to the model instead of individually checking on each of the serializers if possible.
@@ -890,7 +890,9 @@ def create(self, validated_data): | |||
class ForwardNodeAddonSettingsSerializer(NodeAddonSettingsSerializerBase): |
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.
oh my goodness. We have two separate v2 views/serializers which handle updating the forward addon.
PATCH http://localhost:8000/v2/nodes/9bknu/addons/forward/ implemented by Matt in 2016 #6122
PATCH http://localhost:8000/v2/nodes/9bknu/settings/. Erin and I implemented this last year as part of the NodeSettings endpoint #8536.
John's work adds the spam check in Matt's v2 endpoint, but not in ours - NodeSettingsUpdateSerializer. At minimum, both v2 serializers should handle spam checking on the forward addon, but it's my opinion we should deprecate one of them in a follow-up PR, after Emberization occurs.
Matt's: added first, current legacy page uses this v1 view, appears to be documented
Dawn's/Erin's: appears to be documented, if I remember right, this was planned as part of the emberized work? Does Emberized page plan to use to the NodeSettingsSerializer to update the forward addon? (Can you weigh in tomorrow @brianjgeiger ?)
into askismet-redirect-url * 'develop' of https://github.com/CenterForOpenScience/osf.io: (59 commits) Update FAQ link Bump version and update changelog. add license check move comment to docstring fix waffle test fixture make task check DOIs in batches of 20 DRY up row encoding move tests into TCI/linting range gotta pin to trusty for now, my default build xenial is bugged with ES add check for DOI to CeleryConfigs fix/clean-up crossref DOI checking exclude preprints that have only been "stuck" a short time from unsticking process change crossref pending period and fix type make dry_run default to true for DOIs fix test spruce up emails for stuck crossref DOIs save DOI identifier values clean up logging statement for DOIs Bump version and update changelog. use sync_manuscript insteand ...
994f867
to
21ff9af
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.
hey @Johnetordoff - passing back because some of my comments weren't addressed - I think we're pretty close though!
into askismet-redirect-url * 'develop' of https://github.com/CenterForOpenScience/osf.io: (24 commits) Bump version and update changelog. leave Travis confused, but completely unharmed isolate bug feat: expose preprint request actions to requester and preprint admins try new travis config for waffle cookies make osftestcase into pytest for waffle cookie getcwd for Travis remove thrown exception for travis more fixes for travis remove exception catching for request context error move __future__ import to test files only try to fix for travis remove out of context request checking fix for travis fix for travis Remove outdated migration Rename migration and fix dependency Add migration for ab_testing_home_page_version_b waffle flag move and fix waffle tests remove wafflejs urls and comments ...
e956e35
to
0c7fd56
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.
Clarification based on my understanding
b384a49
to
d5549c3
Compare
else: | ||
user = request.user | ||
|
||
self.owner.check_spam(user, {'addons_forward_node_settings__url'}, get_headers_from_request(request)) |
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.
wondering if we should only check spam if the url has actually been changed - instead of every time the forward addon is saved.
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.
Hmmm. From a performance standpoint, I doubt it matters much, since I don't think the forward addon is used much. If we trust the spam filter a lot, then it's better to check each time, in case we modify the spam filter to have a better understanding of what is spam. If we are concerned about false positives (which I don't believe we are), then not checking as frequently is better.
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.
It's a bit of a trade off, if we only want to run this when the user changes something it should probably go back in the serializer.
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 agree with @brianjgeiger, i'm not super concerned about false positives and this isn't going to be run a lot. I do prefer having it on the model since it's being called in 3 places -
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.
👍 agreed I think this is better from a data integrity standpoint and also easier to remove if we depreciate the Forward addon.
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.
LGTM @Johnetordoff 🚢
branch merged into feature/staging-1 for testing |
Purpose
Currently some spammer have taken to using our redirect link feature to funnel traffic to their site. This PR sends the links off to askismet to be vetted.
Changes
addons_forward_node_settings__url
QA Notes
Add spammy redirect links, see what happens.
Documentation
No user face, no docs.
Side Effects
None that I know of.
Ticket
https://openscience.atlassian.net/browse/ENG-607