_csrf is not defined when res.forbidden() is invoked

[boogerlad]

In my layout.ejs file, I use the csrf token for signing in since I use the layout.ejs file as a "main" file where other ejs files get embedded into it as the actual content. Here's the full stack trace

warn: res.forbidden() :: When attempting to render error page view, an error occured (sending JSON instead).  Details:  ReferenceError: /root/cutequickposweb/views/layout.ejs:89
    87|                             </div>
    88|                         </div>
 >> 89|                         <input type="hidden" name="_csrf" value="<%= _csrf %>" />
    90|                         <button tabindex=3 class="btn btn-success" type="submit">Sign in</button>
    91|                     </form>
    92|                     <%}%>

_csrf is not defined
    at eval (eval at <anonymous> (/usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:237:14), <anonymous>:34:2181)
    at eval (eval at <anonymous> (/usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:237:14), <anonymous>:43:3981)
    at /usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:250:15
    at Object.exports.render (/usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:288:13)
    at Object.exports.renderFile (/usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:318:20)
    at module.exports (/usr/lib/node_modules/sails/node_modules/ejs-locals/index.js:85:7)
    at /usr/lib/node_modules/sails/node_modules/ejs-locals/index.js:131:7
    at Object.exports.renderFile (/usr/lib/node_modules/sails/node_modules/ejs/lib/ejs.js:318:3)
    at module.exports [as engine] (/usr/lib/node_modules/sails/node_modules/ejs-locals/index.js:85:7)
    at View.render (/usr/lib/node_modules/sails/node_modules/express/lib/view.js:76:8) { [ReferenceError: /root/cutequickposweb/views/layout.ejs:89
    87|                             </div>
    88|                         </div>
 >> 89|                         <input type="hidden" name="_csrf" value="<%= _csrf %>" />
    90|                         <button tabindex=3 class="btn btn-success" type="submit">Sign in</button>
    91|                     </form>
    92|                     <%}%>

_csrf is not defined] path: '/root/cutequickposweb/views/layout.ejs' }

[Dallas62]

Layout should not be used as a main file.

Do you have enabled sails.config.csrf in config/csrf.js?

refer to: http://sailsjs.org/#/documentation/concepts/Security/CSRF.html

[boogerlad]

It is set to true. If layout.ejs should not be used as main file, then what should?

[Dallas62]

Try to put the form in an other .ejs and include it in your layout.

Sails layouts are special .ejs files in your app's views/ folder you can use to "wrap" or "sandwich" other views. Layouts usually contain the preamble (e.g. !DOCTYPE html....) and conclusion (</html). Then the original view file is included using <%- body %>. Layouts are never used without a view- that would be like serving someone a bread sandwich.

http://sailsjs.org/#/documentation/concepts/Views/Layouts.html

[boogerlad]

I believe you are misunderstanding. I think I'm using layout.ejs properly. Perhaps "main" isn't the best word to describe how I'm using layout.ejs. It contains my header, footer, css and js includes, and other template stuff. My header has a sign in function that should be consistent with each page. Even if I don't have the form in the header, _csrf is still not accessible after a 403.

[Dallas62]

There is a test that use:

csrf=<%= _.isUndefined(_csrf) ? "no_token" : _csrf %> (submit could not work)

https://github.com/balderdashy/sails/blob/f8870e796c22f5f9e39fb9d7c0047d73c82b157e/test/integration/fixtures/sampleapp/views/viewtest/csrf.ejs

but I don't know why res.forbidden() does not include the _csrf

[boogerlad]

Maybe it's the ordering of the middleware?

[loicsaintroch]

Any update about this issue guys?

[CWyrtzen]

Is there any update on this? New info? Old questions?

[sailsbot]

Thanks for posting, @boogerlad. I'm a repo bot-- nice to meet you!

It has been 30 days since there have been any updates or new comments on this page. If this issue has been resolved, feel free to disregard the rest of this message. On the other hand, if you are still waiting on a patch, please:

• review our contribution guide to make sure this submission meets our criteria (only verified bugs with documented features, please; no questions, commentary, or bug reports about undocumented features or unofficial plugins)
• create a new issue with the latest information, including updated version details with error messages, failing tests, and a link back to the original issue. This allows GitHub to automatically create a back-reference for future visitors arriving from search engines.

Thanks so much for your help!