I'm writing backend service that authenticates users. So I must persist users' info including passwords. Let's say we have users manager
package userstorage
type User struct {
Login string
Password string
Nickname string
FirstName string
LastName string
Email string
}
type Manager struct {
users map[string]User
}
func New() *Manager {
return &Manager{
users: make(map[string]User),
}
}
func (m *Manager) Add(user User) error {
// some code
return nil
}
func (m *Manager) Get(login string) (User, error) {
var retUser User
// some code
return retUser, nil
}
It looks good to send User
structure to Add()
method. But when I do Get()
it seems for me not good to return password. Instead it will be better to have method isPasswordValid(login, password string) bool
that will allow class clients to check credentials without giving password.
This leads me to the idea that the User
structure should not include password
field. This means that I must have internal structure to persist all user's info. That looks redundant. So here's the question:
What is the correct class design in this case?
NB. Sure, passwords should be persisted hashed and salted. But anyway it doesn't look good to me to return user's password.
Aucun commentaire:
Enregistrer un commentaire