Da, eh, stim ca trebuie 3000 de interfete pentru diferite adaptoare care nu vor fi folosite, dar vorbim de un posibil PHP 4 sau aplicatii vechi si incerc sa raman in acel context.
Te poti uita peste Codeigniter 1.7.3, e compatibil cu PHP 4.3.2 si are o clasa pentru sesiuni, ar putea fi un punct de start https://ellislab.com/codeigniter/user-guide/installation/downloads.html
JSON Web Tokens nu te-ar ajuta? https://jwt.io/
Ai putea stoca in local storage-ul sau cookie-urile clientului sub forma de payload ceea ce serializai la login in sesiune.
1 Like
nu e foarte reliable, de prea putin timp pe piata ca sa nu aiba gauri
exemplu: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/
nici nu sunt backed up de careva cu nume mare, incat sa fim macar siguri ca daca se reveleaza o gaura ea va fi reparata rapid
am intervenit pt ca am vazut mentionata si o banca, deci e critica solutia aleasa, iar jwt mai are pana la maturitatea aceea
1 Like
Si cu toate astea este foarte folosita in aplicatiile de mobil si unde este nevoie de un sistem de sesiuni descentralizat.
Nu cred ca exista ceva care sa nu aiba probleme de securitate.
Ex (ca tot a avut un ditamai BUG-ul anul trecut): https://www.openssl.org/news/vulnerabilities.html#y2015
ai dreptate, nimic nu e impenetrabil
eu punctam faptul ca un nume mare (google, fb) in spatele unei librarii/tehnologii ajuta la o remediere mai facila a sa in timp decent, ceea ce poate inclina balanta spre ea
absenta unui decision maker expert pe securitate in acea banca se vede destul de clar in acest caz concret, cei care sunt obisnuiti cu politicile stricte (si de multe ori absurde) de “afara” vor intelege exact de ce am simtit nevoia sa evidentiez un lucru ce pare doar o nuanta, fara sa fie insa
3 Likes
Intr-adevar nu are atata autoritate, nici n-ar avea de unde dealtfel dar asta nu inseamna ca 100% nu e safe. Chiar si ascuns in spatele unei companii ca fb sau google poate avea BUG-uri nebanuite 
Am inteles replica ta, eu doar am sugerat, mi s-a parut o rezolvare la problema propusa. Si chiar daca s-ar hotara sa o foloseasca nu cred ca ar folosi o librarie pentru implementarea ei deoarece nu cred ca exista asa ceva pentru PHP 4 si v-a trebui sa o implementeze dupa RFC, adica va elimina librariile alea buguite din link-ul tau.
dupa ce am studiat parerile voastre, am ajuns la concluzia ca o sa raman la sesiuni ca si pana acum.
cineva sugerase mai sus sqlite, dar el fiind ca un fisier pe server, cand 2 useri vor sa scrie in acelasi timp date in sqlite la al doilea i se va da eroare de access (am patito, trebuia sa setez latenta f mare ca sa se reincerce interogarea dupa o anumita perioada) (nu pot scrie intr-un fisier 2 persoane in acelasi timp, cat timp fisierul e deschis de cineva ceilalti doar pot citi nu si scrie)
sqlite e ok cand ai doar 1 user in acelasi timp pe site/aplicatie altfel daca ai mai multi apar probleme (la mysql si alte bd similare nu e problema asta, pot scrie mai multi in acelasi timp fara probleme)
treaba cu json web token e interesanta, dar eu 90% din clienti ii am pe shared host, deci cms-ul meu e gandit sa se descurce cu limitarile unui shared host si nu pot implementa tehnologi care cer vps (gen cine stie ce librarii care nu exista intr-un shared host normal)
la fel, la banca unde am avut problema asta, a trebuit sa fac cerere pentru activarea soap + curl + alte librarii de care era nevoie in cms si sa argumentez pentru fiecare de ce e nevoie de ele, faza cu sesiunile e noua de cateva saptamani si de aici a pornit ideea din discutia asta, ma gandeam ca pot face ceva alternativ, dar intre securitate si alte metode alternative mai putin sigure, aleg mereu securitatea deci raman la sesiuni si astept sa se aprobe cererea de reactivare a sesiunilor pe server
multumesc pentru ajutor si idei, a fost bun acest topic si foarte informativ.
1 Like
stii cum e, daca nu se plateste nu se face 
proiectul e externalizat, doar 2 persoane se ocupa de el (una fiind eu) iar banii sunt limitati, sa facut o oferta pentru refactoring si trecere la php5 dar se va face probabil la toamna cand se va aproba bugetul nou…
in rest, da, cms-ul meu incerc sa il tin la zi cu cea mai noua versiune de php si sa corectez mereu bugurile, dar actualizarile le implementez doar la clientii care platesc nu si la cei care nu isi permit sau cei care vor un site si apoi uita de el fara sa se mai ocupe de el (timpul costa bani si eu nu lucrez pe bete de chibrit)
cand am inceput eu sa invat php acum vre-o 7-8 ani nu stiam de chestia asta, si sistemul implementat in cazul asta e o ramasita de atunci, desigur ca in cron acum nu mai tin cont de sesiuni (am regandit treaba) dar in contextul dat dadusem exemplu unde am avut probleme cu sesiunile la momentul respectiv.
1 Like
unde ai vazut memcache pe shared host? trebuie sa ma limitez la ce optiuni am, stiu ce zici, dar in contextul dat, pe shared host si cu limitarile de librarii existente pe majoritatea acestor tipuri de servere web, sesiuni pentru caching e o optiune buna (aveam de ales intre a mari numarul de interogari pe pagina sau folosirea de sesiuni, iar pe unele shared host dupa cum stii ai si limta pe ora la interogari sql)
Nu sunt obișnuit să lucrez pe shitty servers, under shitty conditions. Tu îți știi mai bine restricțiile. Eu am zis cum aș face eu, my way.