více druhů přihlášení – funkční, ale…

Filip111

Ahoj, řeším více druhů přihlášení na webu, typicky administrátoři na backendu versus zákazník ve frontendu. Celkově mi to funguje, ale nelíbí se mi to – proto bych chtěl poprosit o nápad jak to zapsat do konfigu, příp. jak by to šlo zjednodušit/zpřehlednit.

Přihlášení admina je jasný, budu tedy psát o přihlášení zákazníka:
Zkoušel jsem si vytvořit novou službu User pro zákazníka (customerUser), ale to z nějakého důvodu nejde – instance služby User může být jen jedna, takže jsem Usera ponechal a vytvořil si ve FrontBase presenteru customerUser následovně:

$this->customerUser = $this->user;
$this->customerUser->getStorage()->setNamespace('customer');
$this->customerUser->setAuthenticator($this->context->eshop->CustomerAuthenticator);

Vytvořil jsem nový autentikátor CustomerAuthenticator, který ověřuje identitu nad jinými tabulkami než Autenticator.

Otázky:

funguje to, ale je to správné řešení?
dalo by se to přepsat do neonu, abych měl službu customerUser (podobně jako mam User) a nemusel to řešit v presenteru? Našel jsem, že lze službu v neonu podědit např. customerUser < user ale nevim, jak by šlo donastavit namespace pro storage.

Díky.

jtousek

Ono by to „správně“ asi mělo být tak, že každý administrátor je současně i zákazníkem, jen má nějaká práva navíc. Tzn. že budou existovat dva login formuláře je jedno, fungovat budou oba formuláře na oba typy účtů. Všechny účty budou v db v jedné tabulce s tím že autorizace (IAuthorizator) normální zákazníky do administrace nepustí.

Editoval jtousek (20. 6. 2012 12:28)

Filip111

O tom jsem hodě dlouho uvažoval – nakonec jsem si ale řekl, že funkčně má zákazník k dispozici zcela jiné funkce: vždy bude mít svojí „administraci“ ve frontendu (objednávky, nastavení, apod) a nikdy nebude chodit do opravdové administrace webu. Stejně tak objekt zákazníka je zcela odlišný od uživatele – uživatel má nějaké oprávnění a může spravovat obsah webu, eshopu apod, zatímco u zákazníka mě spíš zajímá nějaká cenová kategorie, slevy, body atd.

Rozhodně je to zajímavý téma – zajímaly by mě názory ostatních.

Díky.

jtousek

Jistě. Ale z jakého důvodu by uživatel neměl mít k dispozici vše co má k dispozici zákazník, tj. ceny, slevy, body…? (+ navíc přístup do administrace) Už kvůli testování by se uživateli tato možnost (imho) hodila.

Ale samozřejmě se nemůžeš řídit jen mým názorem, to ti neberu. :-)

Filip111

Mě se zkrátka nelíbí myšlenka, že když budu upravovat oprávnění nějakého redaktora, že se budu prohrabovat mezi pár admistrátorama smíchaných s několika stovkama zákazníků. Je to nepřehledný, nakonec ještě můžu udělat chybu a nějakýho zákazníka omylem pustim do administrace webu.

Ale z jakého důvodu by uživatel neměl mít k dispozici vše co má k dispozici zákazník, tj. ceny, slevy, body…?
A z jakého důvodu by to měl mít k dispozici? Nenapadá mě jediný užitečný důvod.

LeonardoCA

Důvod? Aby viděl, když něco v administraci nastaví, jak to uvidí zákazník a nemusel se pro kontrolu přihlašovat pod jiným účtem.

Filip111

@LoanardoCA:
ok – ačkoliv v tom nevidím zase takový problém

Ještě nějaké názory a pozitiva? :)

jtousek

Mě se zkrátka nelíbí myšlenka, že když budu upravovat oprávnění nějakého redaktora, že se budu prohrabovat mezi pár admistrátorama smíchaných s několika stovkama zákazníků. Je to nepřehledný, nakonec ještě můžu udělat chybu a nějakýho zákazníka omylem pustim do administrace webu.

Detekce zda uživatel má přístup do administrace nebo ne není tak složitá, takže lze bez problému mít zvlášť výpis zákazníků kteří administrátorská práva nemají a zvlášť výpis pouze administrátorů.

Ale z jakého důvodu by uživatel neměl mít k dispozici vše co má k dispozici zákazník, tj. ceny, slevy, body…?
A z jakého důvodu by to měl mít k dispozici? Nenapadá mě jediný užitečný důvod.

Na to jsem odpověděl už předtím – kvůli testování (viz příspěvek od @LeonardoCA).

Nehledě na to, že když jsem administrátor (např. některý ze zaměstnanců), proč bych měl být omezen a nemohl si např. sám něco objednat? K čemu dva účty?! Navíc by mohl mít třeba zaměstnaneckou slevu.

Editoval jtousek (20. 6. 2012 13:41)

vvoody

Tiez ma hned napadlo ci je dobre rozdelit zakaznikov a adminov, ale ak si si isty ze nenastane situacia ze by si chcel jeden FK nasmerovat na obe tabulky tak potom to bude v pohode.

Ta zmena namespace v storage si myslim ze ani neni potreba, ale ruku do ohna za to nedam :). Ja by som si oba Authenticatory spravil ako sluzbu (co uz asi mas). Userovy nastavil defaultny authenticator, kedze pri prihlaseni by si automatika containeru sama nevedel z tych dvoch vybrat:

user:
	class: Nette\Security\User
	setup:
		- setAuthenticator(@zakaznikAuthenticator)

Pri zakaznikoch by prihlasovanie malo uz ist klasicky a pri adminoch pred volanim $user->login(…) by som ten druhy zobral z containeru a nastavil ho userovy. V podstate tak ako to robis ty, len netreba to robit pri kazdom requeste (asi to mas v startupe presenteru), staci len pred tym prihlasovanim. Ten objekt inokedy nepotrebujes. Taktiez nechapem preco si toho usera prehadzujes do inej premenntej.

Filip111

@vvody:
To přehození do jiný proměnný je blbost – celý je to asi kvůli nepochopení nastavení namespace, viz dokumentace https://doc.nette.org/…thentication#…
Pořád nad tím uvažuju jako o dvou různých službách, ale on je to pořád jen user.

Nicméně po masáži v této diskusi začínám opět uvažovat o jednotné tabulce uživatelů. Zákazníci budou uložený v jiný tabulce ale vygeneruje se jim vždy uživatelský účet a propojí přes nějakou referenci.

jtousek

Ta masáž byla prakticky jen ode mě. :-D I mě zajímal názor @vvoodyho a ostatních na mnou naznačené řešení. ;-)

bojovyletoun

Mě napadá vytvořit 2 presentery – jeden pro zákazníka, kde se bude adminovat objednávku, druhý pro admina, kde bude přidávat zboží. první bude vyžadovat roli admin nebo zákazník, druhý bude vyžadovat roli admin. Vyžadovat to mohou v metodě startup nebo checkrequirements (tam můžeš dát kontrolu na anotaci třeba inRole, ať to nepíšeš furt dokola, nápad zde ) No a někde v administraci pro admina dáš odkaz na ZákazníkAdminPresenter

a samozřejmě při přihlášení zákazník bude mít roli zákazník a admin bude mít admin a zákazník

Editoval bojovyletoun (20. 6. 2012 14:55)

Filip111

@jtousek:
Jenže právě že vvoody se přidal na tvojí stranu :)

Ještě to nevzdávám – stále platí prosba na ostatní:
Jakou s tím máte zkušenost, příp. co je podle vás best practise?
Oddělit účty nebo nechat sloučené?

edit – bojovyletoun přidal další názor, tedy už je to 3:1 pro sjednocení
@bojovyletoun:
S kontrolou rolí nemám problém napříč moduly nebo frontendem/backendem. To je pro uživatele vyřešené, ale u uživateleZákazníka jsem s rolemi nepočítal, nepřipadají mi nutné.

Editoval Filip111 (20. 6. 2012 14:56)

vvoody

sloucene a jak tu vsetci pisu, zakaznik/admin riesit cez role

LeonardoCA

Pro registraci/přihlašování se rozhodně vyplatí mít společnou tabulku users, už kvůli kontrole jedinečnosti emailů a všem ostatním základním funkcím.

Už nějakou dobu řeším uživatelské data přes 2 tabulky.

users – základní informace ve všech projektech stejné – email/heslo/token/datum registrace/čas posledního přihlášení/ počet příhlášení / aktivace účtu / apod. – to mám stejně ve všech projektech

a všechny další údaje uživatele už jsou v každém projektu podle toho co je potřeba v tabulce
users_data – jméno/adresa/telefon/cokoli jiného

data uživatele získávám vždy joinem přes ty dvě tabulky

Brzy budu začínat vlastní projekt, kde budou kromě administrátora 3 naprosto odlišné skupiny uživatelů a tam to plánuju udělat přes role (jak tu píšou i jiní) a společné data v users_data a specifiké data možná přes 3 různé tabulky user_data_role_xxx, ale spíše budou až formou nastavení zakomponovány přímo v nějakých modulech.

Další výhody:

uživatel si nemusí pro přihlášení mít nabídku – přihlásit se jako admin/zákazník/správce/atp – prostě se přihlásí a aplikace ví co mu má zpřístupnit
uživatel může mít i více rolí současně (aktivace a vyplnění dodatečných potřebných dat, atd. lze udělat samostatně)
pro přehlednost v administraci uživatelů jsou filtry a výhoda je mít je pomíchané dohromady, protože vyhledávání podle jména/emailu/atd. zas dá dělat jednoduše a jednotně
veškeré statistiky uživatelů, atd. zas jednotně + specifické informace podle rolí

Myslím, že si mohu dovolit říct:

Rozhodně nikdy nedělte uživatele do více tabulek!

Má to svůj důvod, proč velké firmy vždy nakonec dojdou k tomu, že sloučí uživateleské účty i napříč aplikacemi. (např. google, všechny firmy, které se úspěšně věnují browserovým hrám, atp.)

Dodatek:
Píšu o tabulkách, ale myslím celou správu uživatelů :-)
Stojí to na začátku sice více přemýšlení a práce, ale v budoucnu to ušetří mnohem více času …

Editoval LeonardoCA (20. 6. 2012 16:24)

PavelV

My podobnou situaci řešil pro přihlašování přes facebook, nakonec jsme to zkrouhli trochu spartánsky:

Presenter:

<?php
function actionFacebookLogin() {
	$this->getUser()->setAuthenticator($this->context->facebook)->login($user);
}
?>

třída FacebookService:

<?php
class FacebookService extends \Nette\Object implements Nette\Security\IAuthenticator {
	function authenticate(array $credentials) {
		// ...
	}
}
?>

config:

<?php

# (jak mám formátovat syntaxi configu?)

services:
	facebook:
		class: Moje\Namespace\FacebookService
		autowired: no # jinak Nette křičí, že má dvě instance IAuthenticator
?>

Přihlašování administrátorů ovšem řeším tak, jak ti všichni radí a jak bych ti to radil i já: společnými účty a ACL (které je mimochodem perfektní). I ty FB accounty jsou koneckonců stejná data, jen si ten autentikátor holt musí sáhnout na FB API pro ověření.

Editoval PavelV (20. 6. 2012 20:55)

Filip111

Děkuji pánové za podrobnější rozepsání vašich zkušeností.
Hlavní informace o účtu budou v jedné tabulce podobně jako zmiňuje LeonardoCA, zákazník pak bude mít dodatečné informace v tabulce zákazníka.

Ještě si rozmyslím, jestli ponechám jeden autentikátor nebo jestli použiji dva s tím, že ten pro zákazníka by vracel rozšířenou identitu.

Vytvořím pro zákazníky novou roli a veškeré přístupy se budou nastavovat čistě pomocí oprávnění.