Přihlašování uživatelů – správný návrh

igi

Zdravím, zprovoznil jsem dle návodu přihlašování uživatelů pomocí hash hesla. Třídu implentující authenticate metodu mám ve složce Model, tato třída má jen tuto metodu. Je to takto dobře? Chtěl bych tam dodělat ještě možnost si změnit heslo a poslat zapomenuté heslo a přemýšlím jak to správně rozvrhnout. Měl jsem už napsanou další metodu přímo v mém autentizátoru, ale to je podle mě špatně ne? Protože bych si musel z DI nechat injektovat tu mou třídu, která už je použitá i v samotném přihlašování. Nejspíše tedy vytvořit novou třídu v Model, která bude toto řešit, ve které si injektuji Password třídu? Ještě větší zmatek mám jak poskládat view a presentery. Myslím, že by na tohle měl stačit jen jeden presenter, který by měl tři view? přihlášení,změnu hesla a poslat nové heslo? Jak vyřešit formuláře, v podstatě budou mít některé prvky společné. Vytvořit tedy továrnu na společné prvky a pak tam (nevím jak) dodat zbývající políčka? Děkuji moc předem za rady.

Ondris

Já to většinou rozděluji na authentifikátor, který implementuje Nette\Security\Authenticator a pouze jednou metodou authenticate pro přihlášení. Pak mám další modelovou třídu, která pracuje s tabulkou users a dělá příslušné akce. Přidat, editovat, mazat uživatele atd. Takže tam pak jak píšeš si injectuješ Password třídu a použiješ funkci hash.

Do presenterů bych to rozdělil tak, že bych udělal presenter SignPresenter, kde má přístup i nepřihlášený uživatel a tam můžou být akce jak přihlášení, tak i zapomenutý heslo. Změna hesla je naopak akce přístupná pouze přihlášenému uživateli, takže na to je lepší třeba presenter SettingsPresenter, kde si uživatel může nastavovat různé věci, mimo jiné i změnit heslo. Takže v metodě starup musí být kontrola oprávnění.

igi

Děkuji moc, ještě poslední dotaz – stačí ohledně bezpečnosti kontrolovat zda je uživatel přihlášen a v dané roli pouze v daném presenteru v metodě startup. Nebo z nějakého důvodu je nutné to kontrolovat i v modelech?

dakur

To záleží na tobě. 🙂 Když to kontroluješ v modelu, máš další vrstvu bezpečnosti a máš jistotu, že nikdo z app/cli/api/odjinud nemůže zavolat něco, co by neměl. Vyžaduje to ale samozřejmě další vrstvu kódu, propojení mezi model permissions a app/cli/api/jiné permissions etc. a nemusí se to v dané appce vyplatit.

Editoval dakur (27. 10. 2022 11:16)