You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can't see any attack vector here, so this is just a cleanup opportunity. We seem to be doing this merely for the sake of calling the UserProfile.viewable_nodegroups property. Creating a db row just for the sake of calling a function is something we can avoid: one, to be more RESTful, and two, to shave off a db query.
The text was updated successfully, but these errors were encountered:
UserProfiles always exist since #8022.
1ca5c32 removed some cruft guards for missing profiles.
This removes the rest, which makes it more clear that these GETs
do not have side-effects (and thus CSRF attack vectors).
UserProfiles always exist since #8022.
1ca5c32 removed some cruft guards for missing profiles.
This removes the rest, which makes it more clear that these GETs
do not have side-effects (and thus CSRF attack vectors).
Was reading up on CSRF today and recalled that HTTP GET requests shouldn't have side-effects (and for that reason aren't protected against CSRF).
We have a couple GET views that save
UserProfile
rows:arches/arches/app/views/api.py
Lines 179 to 180 in 3e54931
arches/arches/app/views/api.py
Lines 275 to 276 in 3e54931
I can't see any attack vector here, so this is just a cleanup opportunity. We seem to be doing this merely for the sake of calling the
UserProfile.viewable_nodegroups
property. Creating a db row just for the sake of calling a function is something we can avoid: one, to be more RESTful, and two, to shave off a db query.The text was updated successfully, but these errors were encountered: