CSRF error during API request


(Matt McNeil) #1

I’m attempting to log a user out from an external system (“Single Sign Out”) using the API and the master key. A curl version of my command is:

curl -v 'http://localhost:3001/session/matt?api_key=73179a2cf7c9096f2ec747cb7f85eb67901597d2dccaf707c7c4c614c3f9b371&api_username=matt' -X DELETE

However Discourse complains about invalid CSRF:

I, [2014-06-05T12:20:18.292995 #38691]  INFO -- : Processing by SessionController#destroy as */*
I, [2014-06-05T12:20:18.293955 #38691]  INFO -- :   Parameters: {"api_key"=>"73179a2cf7c9096f2ec747cb7f85eb67901597d2dccaf707c7c4c614c3f9b371", "api_username"=>"matt", "id"=>"matt"}
W, [2014-06-05T12:20:18.296181 #38691]  WARN -- : Can't verify CSRF token authenticity

I thought API requests didn’t check CSRF? Any suggestions on what I’m doing wrong or how to fix?

Thanks much!


(Sam Saffron) #2

I need to get rid of that warning, the actual calls are working fine its just that I need a cleaner way of bypassing the code that logs the warning.


(Matt McNeil) #3

Thanks for the reply @sam !

If the API request is working properly then maybe I have unrealistic expectations as the user appears to remain logged in after the request to session#destroy.

What I’m attempting to do is add functionality such that a user can sign out simultaneously from my external site (which is creating Discourse sessions via SSO) and from Discourse. So before I destroy the session on the external site, I’m sending an API request to Discourse destroy that user’s Discourse session. Am I missing an important concept or just executing it incorrectly?


(Sam Saffron) #4

You cant destroy someone else’s session, you don’t have their session cookie.

I am going to add a “log out user everywhere api” that we can use.


(Matt McNeil) #5

That sounds great. So without that new global logout API, it isn’t really possible to initiate “single-sign-out” from an external site is it?


(Sam Saffron) #6

Yeah, I will try to get it in today, its fairly simple.


(Matt McNeil) #7

Excellent – thanks much for the super quick response!


(Sam Saffron) #8

Implemented now:


(Sam Saffron) #9

Note leaving this open until I remove the nonsense CSRF warning from logs.


(Matt McNeil) #10

Thanks for the new feature!

However I’m still having trouble getting it to work; I’m now getting a 500 error. Is it obvious what I’ve got wrong?

Here’s my request:

I, [2014-06-06T02:42:12.526342 #5216]  INFO -- : Started POST "/admin/users/matt/log_out" for 127.0.0.1 at 2014-06-06 02:42:12 -0700
D, [2014-06-06T02:42:12.545083 #5216] DEBUG -- :   ApiKey Load (1.1ms)  SELECT  "api_keys".* FROM "api_keys"  WHERE "api_keys"."key" = '73179a2cf7c9096f2ec747cb7f85eb67901597d2dccaf707c7c4c614c3f9b371'  ORDER BY "api_keys"."id" ASC LIMIT 1
D, [2014-06-06T02:42:12.547789 #5216] DEBUG -- :   User Load (1.1ms)  SELECT  "users".* FROM "users"  WHERE "users"."username_lower" = 'matt' LIMIT 1
I, [2014-06-06T02:42:12.549650 #5216]  INFO -- : Processing by Admin::UsersController#log_out as XML
I, [2014-06-06T02:42:12.550410 #5216]  INFO -- :   Parameters: {"api_key"=>"73179a2cf7c9096f2ec747cb7f85eb67901597d2dccaf707c7c4c614c3f9b371", "api_username"=>"matt", "user_id"=>"matt"}
W, [2014-06-06T02:42:12.551511 #5216]  WARN -- : Can't verify CSRF token authenticity

and the error:

D, [2014-06-06T02:42:12.622214 #5216] DEBUG -- :   ApiKey Exists (1.3ms)  SELECT  1 AS one FROM "api_keys"  WHERE "api_keys"."key" = '73179a2cf7c9096f2ec747cb7f85eb67901597d2dccaf707c7c4c614c3f9b371' LIMIT 1
D, [2014-06-06T02:42:12.624930 #5216] DEBUG -- :   User Load (1.3ms)  SELECT  "users".* FROM "users"  WHERE "users"."id" = 0 LIMIT 1
I, [2014-06-06T02:42:12.723007 #5216]  INFO -- : Completed 500 Internal Server Error in 76ms
F, [2014-06-06T02:42:12.728816 #5216] FATAL -- :
NoMethodError - undefined method `auth_token=' for nil:NilClass:
  app/controllers/admin/users_controller.rb:61:in `log_out'

#11

Great add…I was looking for this very thing last week.


(Kane York) #12

I think that means that @user is nil. However, I can’t see the code that’s supposed to set ti…


(Matt McNeil) #13

@sam Any thoughts on this 500 error that I’m receiving while trying to use the new admin log_out endpoint? It’s one of the last pieces we need for our Discourse integration.

Thanks much!


(Jeff Atwood) #14

Is this now resolved @sam?


(Sam Saffron) #15

The warning is still there, I need to monkey patch Rails to get rid of it. Not critical to be fixed in v1 @riking’s changes later on with logster can suppress it for now


(Jeff Atwood) #16

(Sam Saffron) #17

Its a bug, I still want it tracked, just don’t need it fixed for v1