Fix authenticity_token bug

[AnkushMalik]

Closes #191

[coveralls]

Coverage remained the same at 85.125% when pulling ba46151 on AnkushMalik:csrf_bug into dc9bba8 on SUSE:master.

[hennevogel]

Hm... have_css already waits the Capybara.default_wait_time so would page.find('#preview-contents'). Why do we need this method? What are you trying to achieve?

[AnkushMalik]

here capybara doesn't wait for our ajax request of previewing markdown to complete so it doesn't find that div.
So from this link, I tried to add this function but the error still persists sometimes 😕 .

[hennevogel]

Did you follow the first link from your blog post? This is what the capybara README has to say:

When working with asynchronous JavaScript, you might come across situations
where you are attempting to interact with an element which is not yet present
on the page. Capybara automatically deals with this by waiting for elements to
appear on the page.

The rest of the thoughtbot blog post is about fixing race conditions between two requests happening at the same time (click_link which triggers the ajax request & reload_page), this is not what is happening here.

So effectively you just have increased the time capbybara waits for the bold and italic elements to appear from 2 seconds (default) to 7 seconds. Which you can also do by setting Capybara.default_wait_time = 7 instead of adding all this code.

So back to my original question, why where you doing this? Did you run into a timeout locally? :-)

[AnkushMalik]

Yes, I was having timeout error, that's why I tried to wait for ajax and also i dont want to increase capybara timeout error just for one feature testing.

[hennevogel]

That's a lot of code for changing something that probably depends on the hardware the test runs on. I would rather read Capybara.default_wait_time from an environment variable so you can set this individually and we can leave the default as it is. Please do it this way :-)

[AnkushMalik]

actually, I think instead of changing capybara's default wait time we should use wait as :

expect(page).to have_selector(:css, "em", text: 'italic', wait: 7)

because capybara will wait for every test whether some element does exist or not.
(please do tell me if I m wrong somewhere 😅 )

However, I think there's some other problem since none of these works, even after waiting or setting the time to 30 seconds! , that's why I tried all those lines of code but even those seem to pass only sometimes ...😕

[hennevogel]

Try just increasing the Capybara.default_wait_time in the helper, see if that helps.

[AnkushMalik]

already did that, no success.

[hennevogel]

I fail to understand how this would fix the problem. It would just skip protection for POSTing json, which we don't do, or do I miss something?

[AnkushMalik]

The token provided by the rails in the beginning and the time we click submit are different because when ajax calls the markdown controller new auth token is provided so I skipped protection only if request format is of application/json.

[hennevogel]

The token provided by the rails in the beginning and the time we click submit are different because when ajax calls the markdown controller new auth token is provided

Sure thing, I understand the problem :-)

so I skipped protection only if request format is of application/json.

What I don't understand is the solution.

1. We GET /markdown/preview?source='## blah' as json. protect_from_forgery isn't used for GET, hence your change doesn't apply.
2. Then we POST the same data to /projects as html. Your protect_from_forgery before_filter isn't used, as it's not json, hence your change doesn't apply.

How does that fix the problem?

[AnkushMalik]

my apologies for the late reply, I used

protect_from_forgery with: :null_session, if: Proc.new { |c| c.request.format == 'application/json' }

after checking these links : 1 & 2 ,since i don't want to close csrf check.

---

protect_from_forgery isn't used for GET

^ I didn't get any strong proof but I think maybe in line:8 protect_from_forgery is triggered only when request.format is application/json 🤔

[hennevogel]

Skipping forgery protection in general is not something we want to do right. But as I said, the only type of requests where forgery protection is running are POST requests. I really don't think you can disable the token update for the session like this by skipping this.

Can you try something? When rendering the preview also change the token of the input field?

<input name="authenticity_token" value="$TOKEN" type="hidden">

There is a view helper called form_authenticity_token that gives you the current token.

[hennevogel]

hey @AnkushMalik thank you for your contributions 💐😍

[AnkushMalik]

failing test cases were resolved in this.

[hennevogel]

Hey @AnkushMalik sorry that I was not responsive for so long. Too much stuff happening in openSUSE/open-build-service 😬 This is exactly what I meant! Thanks.