Based on my interpretation of the code, it seems that:
null_session
should be used in API-style controllers, where you have no use for the session object. This sounds like the appropriate solution for your Angular app. The user’s preexisting session (i.e. as set by other, traditional controllers) will remain intact. It is also the default behavior if you don’t specify awith
option toprotect_from_forgery
.reset_session
is for traditional controllers. When the CSRF check fails, it tells Rails to blow away the user’s session and continue handling the request. This sounds like a “paranoid mode” where you want to log the user out of your app if there is any evidence of tampering in the request.
If your Rails app doesn’t use sessions at all, then these are interchangeable.
However, if you do use sessions in some parts of your app but not others (i.e. a mix of traditional and API controllers), then null_session
is probably what you should use. Otherwise, if you use reset_session
, an API request made by the browser will cause users to be logged out of their browser session.