Ukládání identity návštěvníka - session vs. DB

Používal bych session do té doby než se uživatel přihlásí.

Stejně jako např. u eshopů - procházíš si obchod, dáváš věci do košíku a pokud nejsi přihlášen(a), vše se ukládá do session, nakonec, pokud si opravdu zboží hodláš zakoupit, se musíš registrovat/přihlásit - v momentě přihlášení se data přesunou (resp uloží) do databáze a jsou přiřazeny jednomu id (jednomu zákazníkovi) - s daty v databázi se pak lépe pracuje - jsou jednoznačně přiřazeny, a jsou na tvém serveru (podle mě v lepší struktuře pro práci s nimi) - nejjednoduší je pak identifikovat uživatele podle jejich přihlášení.

no s tím přihlášením bych tak úplně nesouhlasil... použiji-li analogii e-shopu, tak za povinnou registraci pro nákup bych sekal ruce...

Browser a IP je sice dobrá věc, ale jak bylo řečeno, ve spoustě škol, firem atp. se ti téměř všichni uživatelé budou zdát jako jeden (nesmyslné restrikce na používaný prohlížeč, proxy servery a různé podobné chuťovky). A zase naopak někteří provideři směrují požadavky přes zrovna nejméně zatíženou bránu, tudíž se může stát, že ten stejný uživatel bude mít mezi requesty různou IP (asi to ale nebude úplně často)

Obecně, pokud se nejedná o kritická data(browser, ip, iduser, obsah košíku), nebál bych se použít session... to jsou informace, které jsou víceméně přístupné i odjinud a je nesmysl je skrývat... zato s loginem, (nedejbože heslem, nebo hashem hesla) bych už byl opatrnější.

Mezi requesty se přenáší pouze sessionID, tudíž podle mého je dobrá kombinace ukládat si do db k uživateli sessionID (podle toho jestli může být uživatel přihlášen najednou na více strojích implementovat buď jako záznam v tabulce uživatele, nebo samostantou tabulku přístupů) a v session mít iduser... není to neprolomitelné, ale zatím jsem neviděl neprolomitelný kód...
anonymní uživatel se nemusí řešit vůbec, ten nás v této chvíli nezajímá...
samozřejmostí je regenerovat sessionID po přihlášení a odhlášení. Pro zvýšení bezpečnosti se vyplatí implementovat SSL.