backbone.js - l'uso, se un utente è loggato o meno

Question

In primo luogo, se la pagina statica che è servito per l'applicazione essere la pagina di accesso?

In secondo luogo, il mio codice lato server va bene (non darà tutti i dati che l'utente non dovrebbe essere in grado di vedere). Ma come faccio a fare la mia app sapere che se l'utente non è connesso, per tornare ad una forma di accesso?

Answer 1

Ho una chiamata backend che il mio codice lato client che la mia pagina statica (index.php) rende per verificare se l'utente corrente è connesso. Diciamo che c'è una chiamata backend in api/auth/logged_in che restituisce il codice di stato HTTP 200 se l'utente è connesso o 400 altrimenti (usando le sessioni basate su cookie):

appController.checkUser(function(isLoggedIn){
    if(!isLoggedIn) {
        window.location.hash = "login";    
    }

    Backbone.history.start();
});

...

window.AppController = Backbone.Controller.extend({

  checkUser: function(callback) {
     var that = this;

     $.ajax("api/auth/logged_in", {
       type: "GET",
       dataType: "json",
       success: function() {
         return callback(true);
       },
       error: function() {
         return callback(false);
       }
     });
  }
});

Answer 2

Io uso il concetto di sessione per stato di controllo di accesso utente.

Ho un SessionModel e SessionCollection in questo modo:

SessionModel = Backbone.Model.extend({
    defaults: {
        sessionId: "",
        userName: "",
        password: "",
        userId: ""
    },

    isAuthorized: function(){
       return Boolean(this.get("sessionId"));
    }

});

In partenza app, ho inizializzare una variabile disponibile a livello globale, activeSession. All'avvio questa sessione non è autorizzato e eventuali pareri vincolanti a questa istanza modello può rendere di conseguenza. Sul tentativo di accesso, in primo luogo ho il logout da invalidare la sessione.

logout = function(){
    window.activeSession.id = "";
    window.activeSession.clear();
}

In tal modo, tutti i punti di vista che ascoltano l'activeSession e metterò il mio MainView in modalità di accesso dove sarà messo su un account di accesso rapido. Ho poi ottenere il nome utente e la password da parte dell'utente e li misi sul activeSession in questo modo:

login = function(userName, password){
    window.activeSession.set(
        {
            userName: userName,
            password: password
        },{
            silent:true
        }
    );
    window.activeSession.save();
}

In tal modo, un aggiornamento al server tramite backbone.sync. Sul server, ho la messa a punto un'azione POST risorsa sessione in modo che controlla il nome utente e la password. Se valido, riempie i dettagli utente sulla sessione, imposta un unico ID di sessione e rimuove la password e quindi invia di nuovo il risultato.

Il mio backbone.sync è quindi configurato per aggiungere il sessionId di window.activeSession a qualsiasi richiesta in uscita al server. Se l'id di sessione non è valido sul server, rimanda un HTTP 401, che innesca un logout (), che porta alla proiezione del login pronta.

Non siamo del tutto fatto applicazione del presente ancora, quindi ci possono essere degli errori di logica, ma in fondo, questo è il modo in ci si avvicina. Inoltre, il codice di cui sopra non è il nostro codice vero e proprio, in quanto contiene un po 'più logica di gestione, ma è l'essenza di esso.

Answer 3

Ecco un ottimo tutorial per esso http://clintberry.com / 2012 / backbone-JS-apps-authentication-tutorial /

Answer 4

I think you should not only control the html display but also control the display data. Because user can use firefox to change your javascript code.

For detail, you should give user a token after he log in and every time he or she visit your component in page such as data grid or tree or something like that, the page must fetch these data (maybe in json) from your webservice, and the webservice will check this token, if the token is incorrect or past due you shouldn't give user data instead you should give a error message. So that user can't crack your security even if he or she use firebug to change js code.

That might be help to you.

Answer 5

I think you should do this server sided only... There are many chances of getting it hacked unit and unless you have some sort of amazing api responding to it