Domyślnie hasła są haszowane po wstawieniu do auth_user tabeli (poprzez walidator formularzy powiązany z polem hasła). Więc nie chcesz robić standardowego wstawiania SQL haseł w postaci zwykłego tekstu do tabeli (jest to nie tylko niepewne, ale kolejne próby logowania kończą się niepowodzeniem, ponieważ Auth oczekuje zaszyfrowanych haseł).
Najłatwiejszym sposobem wykonania haszowania podczas wstawiania zbiorczego jest przechodzenie przez pętlę rekordów i wstawianie każdego z nich za pomocą .validate_and_insert metoda. Spowoduje to uruchomienie wszystkich walidatorów pól (co spowoduje zahaszowanie haseł), a wszelkie rekordy, które nie przejdą weryfikacji, po prostu nie zostaną wstawione (więc na przykład zduplikowana nazwa użytkownika nie zostanie wstawiona, ponieważ nie powiedzie się weryfikacja).
for user in db(db.user).select():
db.auth_user.validate_and_insert(username=user.username, password=user.password)
Chociaż proces walidacji automatycznie odrzuci wszystkie zduplikowane nazwy użytkowników, jeśli spodziewasz się wielu duplikatów i chcesz poprawić wydajność, możesz najpierw wybrać tylko nieduplikaty od user tabela:
users = db(~db.user.username.belongs(db()._select(db.auth_user.username))).select()
for user in users:
db.auth_user.validate_and_insert(username=user.username, password=user.password)
Pamiętaj też, że domyślnie auth_user tabela wymaga wartości w first_name , last_name i email pola (i poprawny adres e-mail jest potrzebny dla niektórych Auth funkcje, takie jak resetowanie hasła). Dlatego powinieneś albo zaplanować wypełnienie tych pól, albo w inny sposób ustawić ich requires atrybuty na None więc walidacja nie kończy się niepowodzeniem. Na przykład:
db.auth_user.first_name.requires = None
Inną opcją jest zdefiniowanie niestandardowego auth_user tabeli.
