JSON vs URL Encoded API Calls - JSON returns BAD CSRF

Is there possibly a difference in the handling of JSON and formencoded data by the REST API?

If I create a topic it works with Content-Type: application/x-www-formencoded:

POST /posts HTTP/1.1
Content-Type: application/x-www-form-urlencoded

api_key=8d3ca248f3eREMOVEDREMOVEDREMOVEDREMOVEDREMOVED868abd4f&api_username=spero&raw=http://www.youtube.com/watch?v=05zrCwLDkVQ&title=What's Good About Compassion&is_warning=false&category=33&archetype=regular

but not for JSON, returning 403 Forbidden BAD CSRF which makes me think the api key and username are not being pulled from the JSON data the same way they are from the form encoded above. Or did I screw up something in the JSON? Changing the URL to end in .json has no impact.

POST /posts HTTP/1.1
Content-Type: application/json

{ "api_key":"8d3ca248f3eREMOVEDREMOVEDREMOVEDREMOVED868abd4f", "api_username":"spero", "raw":"http://www.youtube.com/watch?v=05zrCwLDkVQ", "title":"What's Good About Compassion", "is_warning":"false", "category":"33", "archetype":"regular" } 

My guess is that as soon as I hit enter whatever silly mistake I made jumps off the page.

Hm, it’s possible Rails doesn’t parse the json as form parameters. What language are you in where form parameters are hard to do?

Forms send inputs as Strings, but shouldn’t “category” be an Int?

I was just prototyping using curl and a REST test tool before starting to code when I found this. It is obviously not a big deal to form encode, but wondering if this may be a generic defect in using the REST APIs with JSON data.

Nice catch on the int vs string @Mittineague, but removing the quotes around the category value does not have an impact on the 403 Forbidden error. If the BAD CSRF problem does get fixed it might then come into play.

Based on the example below, this may have worked at some point in time. It is failing with a fresh upgrade to 1.2.0.beta2.

1 Like

Wow, that’s from the past! I believe there were some issues in the past where a CSRF would bubble up even if that wasn’t the main cause of the error. You may need to still use skip_validations while posting short messages (as you may be hitting the min post length or other checks.) Otherwise, I believe that content posting should be done via json encoded data.

1 Like

No change with skip_validations: true added to the JSON and category properly coded as an integer. And I would have thunk that behavior would be consistent for JSON or form-encoded. Now this is a mission …

POST /posts HTTP/1.1
Content-Type: application/json

{ "api_key":"8d3ca248f3e30e5985a11344568b4ec52a599533f46878bea96f5c5d868abd4f", "api_username":"spero", "raw":"http://www.youtube.com/watch?v=05zrCwLDkVQ", "title":"What's Good About Compassion", "skip_validations": true, "is_warning":false, "category":33, "archetype":"regular" }

I need to patch rails to get rid of that warning its a pain in the behind

Sorry to revive an old topic, but I think this would be helpful to note for future searchers. I didn’t find this information elsewhere.

I was running into this same error when POSTing with JSON data, but I fixed it by just adding the api_key and api_usernames to the URL that’s called.

This is not really a bug, it is a feature request, can be achieved with middleware, not built in to Rails.

Not supporting Content-Type: application/json does make it slightly more annoying to consume the API via curl and other trivial tools. I am open to adding support for this.

2 Likes