2013-07-26 6 views
5

Questo non è stato notato prima, perché per le comunicazioni client-server, nulla richiede autenticazione tramite XHR (fino ad ora). Nell'implementare alcuni test di integrazione, sto creando davvero richieste node-xmlhttprequest a una vera istanza dell'applicazione. L'utente viene autenticato nella prima richiesta e, in teoria, l'identificativo univoco dell'utente e alcune altre informazioni pertinenti vengono archiviati in sessione (come ho già detto, questo funziona perfettamente per i clienti reali, che non devono confermare la propria identità tramite XHR). Per qualche motivo, anche se le richieste successive vengono lanciate con lo stesso identico di sessione, non sono in grado di recuperare la sessione nelle richieste successive e quindi non posso vedere che l'utente sia autenticato, e questo porta a test falliti dove il il comportamento previsto non si verifica e l'HTTP 401 UNAUTHORIZED sta riempiendo il terminale.Express.js/App Passport che crea una nuova sessione per ogni richiesta, nonostante l'ID di sessione nelle intestazioni di richiesta

Ho visto un paio di domande che sembrano un po 'come questo, ma quella cosa "ID di sessione identica" non sembra essere presente tra loro.

Devo aggiungere manualmente le intestazioni Set-Cookie a tutte le richieste XHR? È terribile, deve esserci un modo migliore!

Così la gente come il codice sorgente, ecco qualche dal test, sparano queste richieste:

// Ensure logged in before sending request, to verify that authorized 
// users encounter the expected behaviour. 
jQuery.post(domain+'/login', {email:'[email protected]', password:'12345678'}, 
function(data,x,y){ 
    data.should.equal("true") 
    jQuery.ajax({url:domain+'/event', type:"POST", 
    name: "TestEvent", location: "TestVille", 
    startDate: new Date('2013-09-01'), startTime: '6:45 pm', 
    description: "Test Event #1", success: state.success, 
    error: state.error, completed: state.completed 
    }) 
}) 

Accedi accade, l'ID utente viene scritto nella sessione (`req.logIn() dovrebbe fare questo, ed è non riporta alcun errore), la serializzazione dell'ID utente non riporta alcun errore e sono estremamente confuso sul motivo per cui le successive richieste che utilizzano lo stesso ID di sessione non sono in grado di trovare l'ID utente serializzato.

Generalmente non sono coinvolto nello sviluppo web, quindi questo potrebbe essere ovvio per alcune persone, ma ho cercato una risposta tutto il giorno e semplicemente non sono riuscito a trovarne uno. Apprezzerei qualsiasi suggerimento e sono felice di fornire tutto il codice che sono in grado di illustrare quale sia il problema.

Alcuni ulteriori punti di codice che può essere pertinente:

serializzazione/deserializzazione di ID utente (attualmente implementato nel modo più semplice possibile - Questo è molto presto l'initiallization di middleware, dopo initiallizing passaporto e passpot.session() E questo funziona perfettamente per le richieste non XHR)

// Serialize user for passport session-store 
// Currently only serializing 'user_id' 
passport.serializeUser(function(user, done) { 
    done(null, user._id) 
}) 

// Deserialize user from session-store to provide 
// access to the User instance 
passport.deserializeUser(function(id, done) { 
    User.findById(id, function(err, user) { 
    done(err, user) 
    }) 
}) 

autenticazione degli utenti tramite la strategia locale:.

passport.use(new LocalStrategy({ 
    usernameField: "email", passwordField: "password", 
    passReqToCallback: true, failureFlash: true 
    }, 
    function(req, email, password, done) { 
    User.findByEmail(email, function(err, user) { 
     if(user) { 
     if(err) console.log(err) 
     if(user instanceof UserLocal) { 
      user.verifyPassword(password, function(err, match) { 
      if(err) console.log(err) 
      if(!match) { 
       return done(err, false, 
       "Username or password is incorrect.") 
      } 
      return done(null, user) 
      }) 
     } else { 
     var msg = "Account registered under " + user.providerName() 
       + ", please login using " + user.providerName() 
     return done(err, false, msg) 
     } 
    } else { 
     return done(err, false, "Username or password is incorrect.") 
    } 
    }) 
}) 

E finalmente alle richieste che scrivono alla sessione, in primo luogo:

function loginHelper(req, res, next) { 
    passport.authenticate('local', { 
    failureFlash:true, 
    failureRedirect: false, 
    successRedirect: false 
    }, 
    function(err, user, info) { 
    req.logIn(user, function(err) { 
     if(!err) err = {} 
     if(req.xhr) { 
     console.log(req.session) 
     res.status(200).end(err.message || "true") 
     } else { 
     if(err.message) req.flash('error', err.message) 
     else res.redirect('/') 
     } 
    }) 
    })(req, res, next) 
} 

So che ci sono alcune cose strane come l'invio di uno stato di 200 indipendentemente dallo stato di login, ma posso confermare che l'utente serializzato id viene scritto in sessione sulla richiesta XHR iniziale di accesso e non viene deserializzato nelle successive richieste XHR.

Come credo di aver menzionato, sono relativamente inesperto in questo settore e potrei davvero usare una spinta. Qualsiasi tipo di assistenza sarebbe molto apprezzato, grazie in anticipo.

+1

hai trovato tutte le soluzioni – Sushant

risposta

0

Questo mi Aiutiamo primi

app.use(express.static(__dirname + '/public', { maxAge: oneDay })); 

e aggiornare le funzioni per non innescare banca dati

passport.serializeUser((user, done) => { 
     var sessionUser = { id: user.dataValues.id, fio: user.dataValues.fio, email: user.dataValues.localemail, role: user.dataValues.role, login: user.dataValues.login, position: user.dataValues.position } 
     done(null, sessionUser) 
    }) 

    passport.deserializeUser((sessionUser, done) => { 
     // The sessionUser object is different from the user mongoose collection 
     // it's actually req.session.passport.user and comes from the session collection 
     done(null, sessionUser) 
    }) 

https://www.airpair.com/express/posts/expressjs-and-passportjs-sessions-deep-dive