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_usageik 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:

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 ]