Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A one-time password (aka single-use token) strategy for password resets is something that I'll be implementing. Given Passport's architecture, this can easily be a separate module and it wouldn't surprise me to find out someone else has already implemented such a thing.</p> <p>Remember me and persistence token functionality is also something I'd like to support. Preferably, I'd like that to be a separate strategy as well, but it may need some core support. If that turns out to be the case, a few extra lines in <code>req.logIn</code> ( <a href="https://github.com/jaredhanson/passport/blob/master/lib/passport/http/request.js#L28" rel="noreferrer">https://github.com/jaredhanson/passport/blob/master/lib/passport/http/request.js#L28</a> ) should be able to cover it.</p> <p>As for storing a user ID in the session, I don't see any big risk given that, by default in Connect/Express, session properties are stored entirely in the backend and looked up by a unique <code>sid</code> that is set in an encrypted cookie. A malicious user would have to possess both the unique sid and session secret in order to spoof requests.</p> <p>Mozilla is using Passport as part of their identity effort, to bridge BrowserID to other providers which lack BrowserID support (see <a href="https://github.com/mozilla/browserid-bigtent" rel="noreferrer">browserid-bigtent</a>). Given their requirements, developers can be sure that Passport meets strict security requirements.</p> <p>(Ultimately session serialization in Passport is an application's responsibility, so a random token in place of a user ID can be used if desired for security reasons. Obviously this should be done if storing data directly in the cookie, but I'd suggest that doing that is the most ill-advised approach.)</p> <p>As far as managing those properties on a model, Passport is designed to be completely model/ORM agnostic. I don't intend to ever change that fact, as I think those decisions are best left to the application (and Passport is more flexible as a result of delegating this responsiblity). That said, I think there is room for other modules to independently build on top of Passport to provide this functionality.</p> <p>All that said, I think Passport is the most robust of the existing Node.js auth solutions. Your first three requests would go a long way to making it more so, and they should be easy to accomplish. I'd love to collaborate on getting these features in, so don't hesitate to get in contact with me.</p> <p>Finally, in case anyone is curious, first-class API authentication is presently in the works, on the <a href="https://github.com/jaredhanson/passport/tree/authinfo" rel="noreferrer">authinfo</a> branch. Building on this, <a href="https://github.com/jaredhanson/passport-http-oauth" rel="noreferrer">passport-http-oauth</a> implements OAuth server strategies, which can be combined with <a href="https://github.com/jaredhanson/oauthorize" rel="noreferrer">oauthorize</a> middlware as a toolkit to assemble OAuth servers. This isn't fully baked yet, but it'll be another effective feature of Passport when its ready. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload