-
Notifications
You must be signed in to change notification settings - Fork 124
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
Adding existing works to existing collection fails #1191
Comments
I was unable to duplicate this error. What version of Hyrax are you testing? |
@jcoyne latest on master as of last week. Let me try re-generating and see what happens. |
@jcoyne no, I'm still getting it. I've regenerated the application, and used two different browsers. |
@awead are you seeing this with the test app? or with scholarsphere/another app? If the latter, can you share the contents of |
(I ask because of samvera/hyku#980) |
@mjgiarlo Hyrax test application generated in the hyrax repo. |
I'm getting this too, but only in development mode. |
@awead could this be a turbolinks bug? This is an interesting case where it's trying to submit an authenticity token for a Are we tracking rails/rails#24257 ? |
I did a bunch more testing on this today and confirmed the bug in The button next to the
Only the button on line 34 renders with its own new authenticity token, possibly because of When I 1) disable Turbolinks, and 2) change |
because |
OK, after more testing, I got some stuff wrong earlier. First, turbolinks doesn't seem to be related. As a test, I'm rendering the button twice now, once with It's not the case that |
The method I was using to remove turbolinks was incomplete (removing it from application.js and then recompiling assets). When I remove it from the application's Gemfile and Worth saying, again, that this is not an issue we've seen in Hyku despite it using the same version of Rails (5.1.2) and Turbolinks (5.0.1) that I've been testing with a vanilla Hyrax test app today. |
I wonder if it's due to the version of jquery that is used? |
@jcoyne Ah, perhaps. Hyku uses |
@jcoyne Changing |
FYI... when I pinned rails to 5.0.3, the problem at least appears to have gone away. |
Unclear to me what the proposed fix is for Hyrax. Can somebody clarify? Do we want to bump the version of rails required? Version of jquery required? Do something w/ turbolinks? |
@atz Unclear. Needs more analysis to figure out what the real culprit is. Removing turbolinks seems like a suboptimal solution to me. |
@mjgiarlo Since the problem seems to be limited to this page, we could add |
I wonder if only occurs when: |
Thanks for the tip, @jcoyne! I don't believe anyone's checked this. If this is the case, we should ask folks how they'd feel about twiddling this value. |
Where are we on this issue? I'm asking because we still keep stumbling across this in the collections-sprint branch. We've added turbolinks: false in a number of places, but it would be good to have a general solution. |
@elrayle Where we are: @jcoyne's last comment may provide a clue as to what's causing the root behavior. Until someone looks into the prior point or finds another fix, we've been disabling turbolinks on inbound links. See these two PRs, which you will want to apply to other, similar links in the |
I took another run at this but having no luck.
I tried updating my_controller.rb with several options set on protect_from_forgery...
Presumably
Places I found interesting information...
|
@jcoyne pointed to this github issue as relevant to this conversation... |
I may have figured out what's happening in the case of batch adding works to a collection. It relates to It appears the default setting is to generate a CSRF token for each form, i.e. Normally, this would not be a problem because all of the CSRF tokens that were loaded are valid. Here's the interesting part, in this particular case the token was generated for the action With that being said, it seems like setting |
@jonathandixon Wow, great find! This looks like the same: rails/jquery-ujs#456 And see the workaround suggested here: rails/jquery-ujs#456 (comment) |
@jonathandixon see also @elrayle's message above that suggests setting |
I can confirm that setting |
My last comment is incorrect. Which put's me back at square 1 in trying to figure this out. |
@jonathandixon I haven't had time to dig in, but have you looked at this workaround? rails/jquery-ujs#456 (comment) |
@mjgiarlo I only tried running
I will try to do some more testing after the holidays. |
- Found the root issue is related to turbolinks + jquery-ujs + a button that uses ajax to post. This may also fix #1191. Adding a call to refresh the CSRF tokens in the rendered DOM after turbolinks loads fixes it.
The scenario in this issue has been fixed for a while. And we now have a PR that seems to fix the general issue of turbolinks raising the invalid authenticity tokens exception. See PR #2875. I think we can close this one when the PR is merged. Any objections? @awead @jcoyne @mjgiarlo @no-reply @jonathandixon @atz @martyn-w |
Descriptive summary
Given I have a work owned by me
And I have a collection owned by me
When I visit my dashboard
And select my work
And click "Add to Collection"
And select my collection
And click "Update Collection"
Then I should not see
ActionController::InvalidAuthenticityToken
Expected behavior
My work should be added to my collection
Actual behavior
Steps to reproduce the behavior
The text was updated successfully, but these errors were encountered: