Created
June 6, 2014 23:16
-
-
Save fernandofleury/5963153e30540fdf5f39 to your computer and use it in GitHub Desktop.
Session.js
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
app.factory('Session', [function(){ | |
var set = function(name, data) { | |
sessionStorage.setItem(name, JSON.stringify(data)); | |
} | |
var destroy = function(name) { | |
sessionStorage.removeItem(name); | |
} | |
var get = function(name) { | |
return JSON.parse(sessionStorage.getItem(name)); | |
} | |
return { | |
set: set, | |
destroy: destroy, | |
get: get | |
} | |
}]); | |
// após o login defino o novo usuário na sessao: | |
Session.set('sales', {id: response.id, role: response.role, name: response.name, username: response.username}); | |
// Como eu comentei, no meu caso eu valido a carga inicial no back-end, onde a soma seria id + role + token | |
// (o token fica apenas no back-end e é válido apenas para o ip que realizou o login) | |
// entao se o cara é espertinho o suficiente pra mudar o role na mao, nao vai bater com o role definido junto com o token | |
// se a soma for invalida tenho uma prop no retorno {invalid: true} e verifico ela em todos os requests | |
// caso true $location.path(root); | |
// essa teoria também pode ser aplicada no router, o que evita uma carga desnecessária pro back-end. aí seria o caso | |
// de implementar um auth.check baseado no role necessário para aquela rota. mas ainda é sujeito a alteracao manual quando o cara sabe |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment