Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Modbreak:Deze thread is afgesplitst van [PHP] Opensource PDO classe voor queries
Verwijderd schreef op dinsdag 12 mei 2009 @ 12:59:
Is het gek om met ZF toch je eigen Login systeem te maken terwijl er Zend_Auth is ?

Ik vind het erg makkelijk om allee database typen te kunnen benaderen, echter meer functies heb ik niet direct nodig.

Natuurlijk kies je zelf wat je wil gebruiken, maar zouden er nadelen aan kunnen zitten om Zend_Auth niet te gebruiken ?
In principe is Auth slechts een basis he :) Ik ga binnenkort ook beginnen met het authorisatie-gedeelte van mijn app. Ik wil echter wel bepaalde zaken goed hebben (client stuurt hashed password, meerdere sessies met onafhankelijke ttl's, optionele locks per ip etc). Dat is afaik nog steeds allemaal mogelijk met Zend_Auth als basis. Dus ik zou het lekker gaan gebruiken :)

Het "probleem" is wel dat je steeds meer naar ZF toe gaat. Ik heb er nu voor gekozen om from scratch met Zend_Application te beginnen en alles daarbinnen te doen. Dat werkt heel erg goed, maar het stapsgewijs hier naartoe werken zou veel meer moeite kosten. Bedenk dus _nu_ wat je allemaal wil gaan doen en bereid je daarop voor. Straks voer je veel meer werk uit dan wanneer je nu met refactoren begint :)

[ Voor 4% gewijzigd door Woy op 13-05-2009 10:41 ]


Acties:
  • 0 Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
Zend_Auth is puur een onderdeel om te valideren of een login klopt met verschillende adapters. Ik gebruik het complete MVC patroon van Zend Framework + onderdelen die goed bevallen. Voor authenticatie gebruik ik n eigen systeem met session management (praktisch t zelfde als t op T.net werkt) en eigen ACL systeem. Ik vind Zend_Acl ook te beperkt namelijk. Je kunt ook gewoon een eigen library map erin knallen van jezelf Jouwnaam_Auth in de map Jouwnaam/Auth.php zoals ZF in elkaar zit (handig met autoloading) :)

Acties:
  • 0 Henk 'm!

  • iH8
  • Registratie: December 2001
  • Laatst online: 17-06-2024

iH8

Cartman! schreef op dinsdag 12 mei 2009 @ 22:56:
Zend_Auth is puur een onderdeel om te valideren of een login klopt met verschillende adapters. Ik gebruik het complete MVC patroon van Zend Framework + onderdelen die goed bevallen. Voor authenticatie gebruik ik n eigen systeem met session management (praktisch t zelfde als t op T.net werkt) en eigen ACL systeem. Ik vind Zend_Acl ook te beperkt namelijk. Je kunt ook gewoon een eigen library map erin knallen van jezelf Jouwnaam_Auth in de map Jouwnaam/Auth.php zoals ZF in elkaar zit (handig met autoloading) :)
wat kom jij zoal te kort aan Zend_Auth, Acl & Session dan?,

Aunt bunny is coming to get me!


Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Voorlopig kom ík niet te kort aan Zend_Auth in ieder geval.

Ik hash passwords met SHA1 en dat is te implementeren. Ik gebruik cookies en een sessie tabel in de database voor persistent storage en dat moet ook gewoon mogelijk zijn (ben ik nu mee bezig). Afaik is er voor mij iig nu nog geen reden om Zend_Auth te extenden.

Waar ik wel meer moeite mee heb is Zend_Acl. Daar zit ik nu met eigen rollen, resources en allerlei plugins om dit op te vangen. Nog steeds is het best nette code, maar ik had ook een geheel eigen implementatie kunnen schrijven.

Acties:
  • 0 Henk 'm!

  • iH8
  • Registratie: December 2001
  • Laatst online: 17-06-2024

iH8

mithras schreef op woensdag 13 mei 2009 @ 00:20:
Voorlopig kom ík niet te kort aan Zend_Auth in ieder geval.

Ik hash passwords met SHA1 en dat is te implementeren.
dat kan nog beter met een static salt en een random salt :) en je kunt ook nog eens condities meegeven ook. erg mooi.

PHP:
1
$authAdapter->setCredentialTreatment(SHA1(CONCAT(SHA1('".$authSalt."'), SHA1(?), SHA1(salt))) AND active = 1 AND block = 0 AND ban = 0");
mithras schreef op woensdag 13 mei 2009 @ 00:20:
Ik gebruik cookies en een sessie tabel in de database voor persistent storage en dat moet ook gewoon mogelijk zijn
gewoon je eigen handler aan Zend_Session doorgeven en custom storage aan de instance van je authadapter:

PHP:
1
2
3
Zend_Session::setSaveHandler(new Zend_Session_SaveHandler_DbTable($config->session));

$authInstance->setStorage(new Zend_Auth_Storage_Session('User'));


http://framework.zend.com....savehandler.dbtable.html
http://framework.zend.com...ction.persistence.default
mithras schreef op woensdag 13 mei 2009 @ 00:20:
Waar ik wel meer moeite mee heb is Zend_Acl. Daar zit ik nu met eigen rollen, resources en allerlei plugins om dit op te vangen. Nog steeds is het best nette code, maar ik had ook een geheel eigen implementatie kunnen schrijven.
het valt mij niet tegen gelukkig.

Aunt bunny is coming to get me!


Acties:
  • 0 Henk 'm!

  • ZpAz
  • Registratie: September 2005
  • Laatst online: 15:23
Zend_Acl heb ik sinds gister mee gespeelt, en heb het dmv de een Front_Controller plugin, waar de resources de controllers en actions zijn, en de roles de standaard users.

Voordat een request dan gedispatched wordt gaat hij eerst langs mijn plugin welke kijkt of er wel toegang is op die bepaalde controller en bijbehorende action.

Zo kan ik mijn ACL structuur mooi scheiden van de rest van de code.

Tweakers Time Machine Browser Extension | Chrome : Firefox


Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
iH8 schreef op woensdag 13 mei 2009 @ 01:03:
[...]

dat kan nog beter met een static salt en een random salt :) en je kunt ook nog eens condities meegeven ook. erg mooi.

PHP:
1
$authAdapter->setCredentialTreatment(SHA1(CONCAT(SHA1('".$authSalt."'), SHA1(?), SHA1(salt))) AND active = 1 AND block = 0 AND ban = 0");
Ja, een static salt is eigenlijk nog mooier.

Maar de passwords staan SHA1 in de database. Zonder Framework haalde ik die op en vergeleek ik volgens $userInput = sha1( $salt . $databasePassword ). Wat jij doet is iets anders (niet per se minder of beter afaik).
[...]
gewoon je eigen handler aan Zend_Session doorgeven en custom storage aan de instance van je authadapter:

PHP:
1
2
3
Zend_Session::setSaveHandler(new Zend_Session_SaveHandler_DbTable($config->session));

$authInstance->setStorage(new Zend_Auth_Storage_Session('User'));


http://framework.zend.com....savehandler.dbtable.html
http://framework.zend.com...ction.persistence.default
Nou, het gaat puur om het gedeelte van meerdere sessies opslaan in de database. Ik wil niet voor alles waarbij ik Zend_Session inzet de database gaan gebruiken, dat kost veel te veel.

Wat ik in mijn hoofd had zitten is dat ik met $result->getResultRowObject() de username en id terugkrijg. Deze sla ik dan op in de database. Ook zet ik een cookie met sessieId. Met een plugin kijk ik dan of de match van cookie en database entry ok is. Als dat zo is, zorg dan dat Zend_Auth de identity goed pakt.
Maar dit klinkt nogal omslachtig. Hoe zou het beter kunnen dan?
[...]

het valt mij niet tegen gelukkig.
Misschien is tegenvallen een groot woord :p Ik wil dit als basis nemen, maar dan voor CMS pagina's. Je krijgt dus pagina's binnen een bepaalde categorie (cq domein). En rollen voor gebruikers en groepen (al moeten groepen ook rechten kunnen overerven). Op zich niet heel moeilijk dus, maar alsnog veel zelf schrijven (ook dat is niet erg hoor).

Acties:
  • 0 Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
iH8 schreef op dinsdag 12 mei 2009 @ 22:59:
[...]
wat kom jij zoal te kort aan Zend_Auth, Acl & Session dan?,
Zend_Session is iets anders dan een sessionmanager voor logins. Ik wil een persoon meerdere keren kunnen in laten loggen en remote andere logins killen. Ik sla enkel een cookie op met (evt. door user zelfgekozen lifetime) een hash erin die kan id-en welke user het is.

Zeld_Acl heb ik even naar gekeken maar ik kon geen geautomatiseerd systeem bedenken die het nuttig maakt. Ik sla in de database groepen op met specifieke rechten. Een user kan in meerdere groepen zitten zodat rechten opstapelen of juist weer verwijderd worden (conflicthandling) en evt. kan je per user nog extra rechten toevoegen of afnemen. Enorm flexibel dus en allemaal via een simpele admin in te stellen. Ik mn controller of views hoe ik enkel dit te doen:

PHP:
1
2
3
4
if(TRUE == $this->checkPermissions(array('recht1', 'recht2')))
{
    // laat iets toe
}


en in welke groep of welk userid de gebruiker heeft maakt niet uit, zolang ie die rechten maar heeft.

Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Cartman! schreef op woensdag 13 mei 2009 @ 10:44:
[...]

Zeld_Acl heb ik even naar gekeken maar ik kon geen geautomatiseerd systeem bedenken die het nuttig maakt. Ik sla in de database groepen op met specifieke rechten. Een user kan in meerdere groepen zitten zodat rechten opstapelen of juist weer verwijderd worden (conflicthandling) en evt. kan je per user nog extra rechten toevoegen of afnemen. Enorm flexibel dus en allemaal via een simpele admin in te stellen. Ik mn controller of views hoe ik enkel dit te doen:

PHP:
1
2
3
4
if(TRUE == $this->checkPermissions(array('recht1', 'recht2')))
{
    // laat iets toe
}


en in welke groep of welk userid de gebruiker heeft maakt niet uit, zolang ie die rechten maar heeft.
Dat is precies wat Zend_Acl ook gewoon kan :p Check deze link die ik hier noemde.

Ik heb dus een MyApp_Acl_Resource_Page en MyApp_Acl_Resource_Category waarbij een page in een categorie zit ($page->getCategory()) en categorien hierarchisch zijn ($category->getParents()).
Verder heb ik een MyApp_Acl_Role_User en MyApp_Acl_Role_Group. Daar zit een gebruiker in meerdere groepen ($user->getGroups()) en kunnen groepen ook hierarchisch zijn ($group->getParents()).

Vervolgens doe ik in de plugin zoiets:
PHP:
1
2
3
$factory = new Soflomo_Acl_Factory();
$resource = Soflomo_Acl_Resource_Page( $params );
$acl = $factory->createPageAcl($resource, $user);

Vervolgens maakt de factory eerst een categoryAcl waarin de category + parents worden toegevoegd als resources. Ook voeg je alle voorkomende rollen toe van die categorie. Dan worden alle privileges van die categorieën toegevoegd. Daarna hetzelfde voor de pagina.

Tot slot check je of de role, resource en permissie bestaat. Dan heb je een best complex systeem, maar toch steeds het gemak van Acl. En omdat mijn cms toch slechts uit pagina's in categorieën bestaat en er gebruikers zijn in groepen, kan ik dit alles in een preDispatch() hook doen.

Dan valt zelfs de hele controle in de controllers weg. Tenminste wel op het gebied van iets mogen zien of niet. Uiteraard moet je nog wal apart controleren of je mag reageren, iets wijzigen etc.

Acties:
  • 0 Henk 'm!

  • Cartman!
  • Registratie: April 2000
  • Niet online
Dat is een beetje t ding, Zend_ACL is of net te simpel en als je ermee wilt doen wat ik wil dan lijkt het ineens nodeloos complex te zijn en vreet het resources (denk ik, correct me if im wrong). Desalniettemin zal ik er wanneer ik er tijd voor heb er eens rustig naar kijken :)

edit: ben toch benieuwd hoe je alles volledig vanuit een database beheert, zou je dat kunnen toelichten?

[ Voor 16% gewijzigd door Cartman! op 13-05-2009 12:39 ]


Acties:
  • 0 Henk 'm!

  • mithras
  • Registratie: Maart 2003
  • Niet online
Cartman! schreef op woensdag 13 mei 2009 @ 12:34:
Dat is een beetje t ding, Zend_ACL is of net te simpel en als je ermee wilt doen wat ik wil dan lijkt het ineens nodeloos complex te zijn en vreet het resources (denk ik, correct me if im wrong). Desalniettemin zal ik er wanneer ik er tijd voor heb er eens rustig naar kijken :)

edit: ben toch benieuwd hoe je alles volledig vanuit een database beheert, zou je dat kunnen toelichten?
Check dit plaatje (gaat over bestanden, maar pagina's in een cms zijn voor mij hetzelfde)
Afbeeldingslocatie: http://codeutopia.net/acl_file.jpg

Wat ik doe is:
  1. Bekijk of een pagina in een categorie zit
  2. Voeg alle categorieën toe als resources
  3. Bekijk de entries van privileges waar de categorie in voorkomt
  4. Creëer op basis van de role_id de Acl_Role
  5. Wanneer de role een user is, zoek alle groepen op en maak daar ook Acl_Role instanties van
  6. Voeg alle rollen toe aan de acl
  7. Neem alle permissies die voorkomen (dus de entries van privileges) en voeg de mode toe (bijv 'allow' en 'deny').
  8. Doe dit nog een keer voor je pagina resource (stap 2 t/m 7)
Nu heb je voor de pagina slechts de permissies toegevoegd die ook daadwerkelijk voorkomen voor dat gedeelte. Je verspilt in deze zin geen resources omdat je niet gaat kijken of iemand admin rechten heeft wanneer je een blog artikel bekijkt.
Daarom controleer ik ook of de role en resource bestaat, want wanneer je geen rechten hebt, kom je ook niet in de acl voor, tenzij je dat expliciet definieert (dmv deny). Je hoeft niet aan te geven dat gasten geen toegang hebben tot de admin. Je definieert er gewoon niets voor.

En in dit geval kan je dus per categorie / group privileges regelen, maar ook nog eens per pagina en/of user (hoewel ik dat laatste niet gebruik). Daarmee heb je -een voor mij groot genoeg- systeem.

/edit: Ow, en een hoop van de stappen valt te cachen, dus je loopt ook niet de hele tijd data van je database te trekken. Daar kan je op klasse, functie of query niveau Zend_Cache voor inzetten :)

[ Voor 4% gewijzigd door mithras op 13-05-2009 13:02 ]


Acties:
  • 0 Henk 'm!

  • iH8
  • Registratie: December 2001
  • Laatst online: 17-06-2024

iH8

mithras schreef op woensdag 13 mei 2009 @ 08:59:
Ja, een static salt is eigenlijk nog mooier.

Maar de passwords staan SHA1 in de database. Zonder Framework haalde ik die op en vergeleek ik volgens $userInput = sha1( $salt . $databasePassword ). Wat jij doet is iets anders (niet per se minder of beter afaik).
ik heb een static salt in mijn configuratie opgenomen, die is door heel de app heel voor iedereen hetzelfde. bij het aanmaken van een user sla ik een random generated salt op. het password sla ik gehashed op als static.password.random. lijkt mij veiliger dan alleen een enkele salt in de database of applicatie.
You can improve security even more by using a static salt value hard coded into your application. In the case that your database is compromised (e. g. by an SQL injection attack) but your web server is intact your data is still unusable for the attacker.
http://framework.zend.com...e.advanced.advanced_usage
mithras schreef op woensdag 13 mei 2009 @ 08:59:
Nou, het gaat puur om het gedeelte van meerdere sessies opslaan in de database. Ik wil niet voor alles waarbij ik Zend_Session inzet de database gaan gebruiken, dat kost veel te veel.
ik beschik jammer genoeg niet over een dedicated server daarom draait ik vanwege security de sessies in een database. shared hosting, je weet 't nooit. van dat dat teveel kost heb ik nog niets gemerkt gelukkig. ik houd tussendoor goed de firebug-profiler in de gaten:

Afbeeldingslocatie: http://members.chello.nl/p.verhoeven01/firebug_profiler.png
mithras schreef op woensdag 13 mei 2009 @ 08:59:
Wat ik in mijn hoofd had zitten is dat ik met $result->getResultRowObject() de username en id terugkrijg. Deze sla ik dan op in de database. Ook zet ik een cookie met sessieId. Met een plugin kijk ik dan of de match van cookie en database entry ok is. Als dat zo is, zorg dan dat Zend_Auth de identity goed pakt.
Maar dit klinkt nogal omslachtig. Hoe zou het beter kunnen dan?
ik schrijf het resultRowObject in zijn geheel weg in een sessie namespace 'User'. die lees ik dan naderhand gewoon weer in. dat object kan gewoon bevatten wat jij noodzakelijk vindt.

PHP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
$authRequest = $this->_request->getPost();
$authAdapter = $this->_getAuthAdapter($authRequest);
$authInstance = Zend_Auth::getInstance();
$authInstance->setStorage(new Zend_Auth_Storage_Session('User'));
$authResult = $authAdapter->authenticate();

 // authData zonder hash en salt
$authData = $authAdapter->getResultRowObject(null, array('hash','salt'));

// authData alleen id en username
$authData = $authAdapter->getResultRowObject(array('id','username'), null); 

$authStorage = $authInstance->getStorage();
$authStorage->write($authData);

// ophalen
$userSession = new Zend_Auth_Storage_Session('User'); 
$userData = $userSession->read();
var_dump($userdata);

//object(stdClass)#22 (5) {
//  ["id"]=>
//  string(1) "666"
//  ["username"]=>
//  string(3) "iH8"
//  ["active"]=>
//  string(1) "1"
//  ["block"]=>
//  string(1) "0"
//  ["ban"]=>
//  string(1) "0"
//}

// dumpen
$userSession->clear();
$userData = $userSession->read();
var_dump($userData);

// null


ik heb wel ff een stuk weggelaten voor de duidelijkheid: user group en role zitten ook in mijn object, dat object gebruik ik dan weer gewoon in Zend_Acl, adhv de role zet ik dan de sessionNamespace en wanneer die namespace expires. voor een admin op 15 minuten en een normale user een uur bijvoorbeeld. je kunt heel mooi namespaces afzonderlijk laten expiren

PHP:
1
2
$userSession = new Zend_Auth_Storage_Session('User'); 
$userSession->setExpirationSeconds(60);


http://framework.zend.com...advanced_usage.expiration

dit is dus wel iets anders als Zend_Session::destroy(); ik heb mijn sessie nog voor andere zaken nodig als alleen authorisatie. vind dit so far erg fijn werken. maar ik ben er nog niet klaar mee dus er kan best nog het één en ander veranderen. kan zijn dat ik fouten maak etc, ik ben nieuw met OOP/MVC en Zend Framework maar ik trek 't goed :+

edit: dat authResultObject behouden is nog helemaal niet zo verkeerd ;)
Typically in Zend Framework, you'll authenticate a user using Zend_Auth, which will persist their "identity" in the session. This "identity" can be anything: a string, an array, an object. This latter gives some fantastic potential: if the object implements Zend_Acl_Role_Interface, then it can be used for ACL checks.
http://weierophinney.net/...lying-ACLs-to-Models.html

^ da's Auth/Acl gezien the way, vinnik :)

[ Voor 6% gewijzigd door iH8 op 13-05-2009 15:29 . Reden: kleinheidje toegevoegd ]

Aunt bunny is coming to get me!

Pagina: 1