Bonjour à vous...
 
J'aimerais savoir un truc...
 
Imaginez qu'on puisse éditer un fichier PHP comme [CONFIG.PHP]...
 
Contenant chacune des variables suivantes :  
 

 
Et imaginez qu'on utilise la technique du INCLUDE... (pour connaître la valeur de ses variables)...
 
Finalement, on pourrait se recréer un système de SESSIOn encore plus performant que celui actuelle non ?
 
Car, on pourrait très bien faire conf156.php pour le membre d'id 156, etc....
 
Qu'en pensez-vous ?
 
n'est-ce pas une bonne idée ?
 
Est-ce meilleur ou pas qu'une TABLE SQL temporaire ?
 
salutations et merci pour vos réponses

j'ai rien compris

> Finalement, on pourrait se recréer un système de SESSIOn encore plus performant que celui actuelle non ?
 
Je vois pas du tout en quoi ce serait plus performant ... Le principe est en tout point identique, après seuls des détails diffèrent (stockage des variables "en texte brut" au lieu de serialisées, mais je suppose que si le PHP Team a choisi cette méthode sur le système de session de PHP4 c'est qu'il doit y avoir une raison, ce serait-ce que pour les tableaux)=.

Core 666 > me demande plutôt si il mélange pas fonctionnalités du langage et besoins applicatifs (en l'occurence, ses propres besoins) pour proposer une nouvelle version du langage

rien compris.....

ce n'est pas très clair ta question...

Je vais essayer d'être clair et concis.
 
Je souhaiterais savoir si le système de session actuel du langage PHP serait plus performant si :
 
- au lieu d'utiliser des tables SQL temporaires, il utilisait des REWRITE(fichier)... Enfin bref, des écritures de fichiers TEXTES.
Ces fichiers contiendraient les infos que j'ai montrées ci-dessus...
 
- la méthode serait de ne pas devoir se "connecter à la base sql"... ni de devoir créer des tables temporaires puis les supprimer (ce qui est inutile)...
 
Je pense donc à un fichier PHP créé (faudrait donc enlever les attributs de lecture seule mis par défauts pour le répertoire "/sessions" ) au lieu d'une table SQL temporaire...
 
Et donc, au lieu de faire un "create_table.... puis connect_sql()...deconnect_sql()", le système ferait simplement un "rewrite($fichier) ... puis un "include($fichier)" pour lire le contenu des variables
 
Enfin, voilà donc mon idée;..

Et les sessions classiques ne te suffisent pas ?

relis... j'ai changé

 

 
comme je te l'ai déjà dit dans un autre topik .... une session n'est pas forcement stocké en bdd
elle peut aussi etre stocké dans un fichier ! celui ci ne comprte pas l'extension php mais .. il fonctionne grossièrement comme tu le décris mais les données sont linéarisée (voir post de Core 666)

GENIAL !
 
je l'ignorais
 
quelqu'un m'avait pourtant dit qu'il fonctionnait en BASE de données... (celle intégrée par défaut avec le serveur PHP)  
 
il avait dû se tromper...

Ah oui ok. Donc : Et les sessions classiques ne te suffisent pas ?
 
 
Tu utilises des tables temporaires pour utiliser les sessions php toi ?

j'ai jamais dit ça (tu déformes tout lol)
 
j'ai dit qu'on m'avait dit que le système de session faisait cette création temporaire de table sql...
 
peut-être s'était-il trompé ?
 
ou peut-être qu'on peut modifier le paramétrage de la session via le INI du PHP ?

Ayé j'ai compris ce que tu voulais dire. Que PHP gérait lui même les sessions avec des fichiers temp...Je peux me tromper, mais il me semble que c'est plutot des fichiers que php utilise...

 
Oui, c'est ça, puisqu'en principe souvent il faut crééer un répertoire où seront stocké les sessions.
 
allopassxp >> tu veux faire quoi exactement avec les sessions ? J'ai l'impression que tu n'as tout à fait compris à quoi ça servait.

ah si.... bien sûr;.. c'est juste que je n'avais jamais lu la façon dont PHP gérait les sessions, alors je l'imaginais...
 
et bien... avec les sessions, je souhaite pouvoir faire un espace membre SANS COOKIES... parce qu'on m'a dit que l'utilisation de cookies était très peu sécuritaire... de plus, on m'a dit qu'il fallait travailler UNIQUEMENT en register global=off... sinon, ce n'est pas du tout sécuritaire... actuellement, j'utilise le "session_start" de PHP... mais cela ne me sert presque à RIEN... puisque le seul intérêt d'une session et de ne pas écrire, dans les urls, les logins et passwords en "toutes lettres"...
 
car, étant donné que le système de session actuel utilise des COOKIES (chez le client), ça veut donc dire qu'il aurait suffit de stocker ces cookies en mémoire afin de pouvoir en faire des outils d'accès à son espace membre...
 
enfin... ce que je veux dire... c'est que faire des sessions SANS COOKIES est hyper intéressant pour la sécurité, car personne ne pourra "accéder" au mot de passe sur un même ordinateur... celui-ci ne sera entré par l'utilisateur qu'une seule fois... et si ce même utilisateur refuse de "sauvegarder son mot de passe en cookies", et bien, il devra à chaque fois se reconnecter... et la session fait donc son boulot, tout naturellement... mais SANS COOKIES... comme ça, les gars n'ayant pas de cookies sur leur navigateur pourront utiliser le système de session !!!!!!!!!! de plus, celui-ci, est plus sécuritaire...
 
salutations

tu dois pas stocker le mot de passe dans un cookie...
 
tu dois juste , via session_start, demander a php de propager un id... ensuite tu regarde si une variable de session (donc un fihcier texte) ou bien si une ligne de base de donnée (via une gestion manuelle) contient quelque chsoe en rapport avec cet id...
 
si le gars a désactivé les cookie, php se chargera tout seul de propager l'id via l'url...

Bon on va y aller pas par pas :
 

 
C'est mauvais de faire des revolutions si on sait pas sur quoi elles portent
 
 
 

 
Tu oublie les $_POST, et les session c'est pas pour ne pas ecrire dans l'url les variable, c'est pour les conserver tout au long du site.
 

 
Rien compris de ce que tu racconte .. aufait juste pour te dire, les cookies créé chez le client par le serveur ne contiennent aucune donnée utilisable pour acceder aux données stockées , le ficher ne contient qu'un numero d'id  
 

 
Voir commentaire d'avant
 
En resumé, je crois que le mieux pour toi c'est d'abord de comprendre comment marche une session, apres de savoir l'utiliser comme il faut et une fois que c'est fait tu verras que ton truc tiens pas trop debout.
 

Au revoir

 
t'avais pas dis que t'arretais de dire des conneries ?  
 
sérieusement, tu n'as pas tt à fait tort mais pas tt à fait raison non plus.
 
- l'utilisation de cookie n'est pas forcement moins sécurisé !
- l'utilisation de session avec passage de l'id dans l'url (donc ss cookie) constitue une grosse faille de sécurité.
- l'utilisation session/cookie de session est ss doute une des meilleures manière de proceder en terme de sécurité.
 
edit : lis des tutos et tips, tu apprendras des choses qui te serviront   (et tu diras moins de conneries )

 
non, c'est archi faux...
car poiur cela, il faut écrire des session_name() et session_id()
c'est pas si simple

[citation]
- l'utilisation de cookie n'est pas forcement moins sécurisé !
- l'utilisation de session avec passage de l'id dans l'url (donc ss cookie) constitue une grosse faille de sécurité.
- l'utilisation session/cookie de session est ss doute une des meilleures manière de proceder en terme de sécurité.
[/citation]
 
Bah écoute... c'est un gars que j'ai payé 300 euros qui m'a certifié que les sessions sans cookies étaient les plus sécurisées... et qu'il fallait dans chaque url, transmettre les session_name() et session_id()... cela étant plus sécurisé et surtout fonctionnant sur tous les ordinateurs (même ceux n'autorisant pas les cookies sur leur navigateur)...
 
la transmission par URL est donc simplement plus "lourd" pour le client, mais est compatible avec tous les navigateurs (y compris ceux qui ont désactivé les cookies ou les "cookies des session" )
 
salutations

t'as perdu 300 € ?

 
génial ... moi je facture 500, tu me fais confiance maintenant ?
 
crois ce que tu veux, j'en ai rien a foutre mais c'est un dialogue que tu cherches ou à divulger ton savoir ? ce savoir là, moi j'en veux  

 
fait comme tu veux
 
seulement j'espere pour tout ceux qui utilisent des sessions que tu feras jamais partie de la php team meme en payant 300€ ...

http://fr2.php.net/manual/fr/ref.session.php  
Paragraphe Sessions et sécurité  

Allopassxp , si je t'explike que pour securiser ton systeme au maximum il vaut mieux enregistrer tes login/mdp dans secu.txt et y acceder avec un script JS (pask les DB peuvent etre violés et apache n'es pas sans failles) tu me paies aussi 300 euro?

je paye 300 euros pas pour une explication de deux lignes
 
salutations cordiales
 
ps : t'es plus parano qu'efficace... car l'APPACHE... a vraiment été amélioré... et il est en théorie, sans faille.... du moins, sur un serveur dont le noyau est régulièrement remis à jour

je suis con et on se fout peut-être un peu de ma gueule
 
mais, je suis radin comme picsou

oui, je le confirme toujours...
 
par contre, je suis généreux malgré ma radinerie
 
en résumé, je sais pas si je peux réellement me qualifier de radin
 
PS : au fait... j'ai toujours exactement la même idée des [ sessions ]
 
et je confirme que sans cookies, c'est plus sécurisé (selon moi), mais en fait, c'est surtout PLUS OPERATIONNEL pour n'importe qui dans la mesure où même quelqu'un interdisant les cookies sur son nagivateur pourra tranquillement utiliser sa session et PERSONNE (donc, c'est sécurisé) ne pourra par la suite utiliser ses codes d'accès !!! car NI cookies enregistrés, ni trace de session...
 
maintenant, si on stocke l'ID de session DANS UN COOKIES...  
 
et bien, si le webmaster OUBLIE l'url... et bien, il l'a dans le "cul" dans le cas où l'internaute n'as pas AUTORISE ses cookies (donc, c'est plus "sécurisé" dans la mesure où ça MARCHE TOUT LE TEMPS...
 
bien sûr, quelqu'un peut s'amuser à écrire n'importe quoi dans l'url de session... mais ce n'est pas pour autant que ça faussera quoi que ce soit, puisqu'un identifiant FAUX de session est équivalent à une SESSION NON OUVERTE (vous serez tous d'accord avec moi)
 
@+ les programmeurs

/*MEGA OFF mais ça me saoule
 
t1 g posé un problème qui peut intéresser les gens à propos de gd2, personne n'a répondu, et quelqu'un qui lit 0 doc vous vous acharnez dessus.. c quoi ce travail ??  
 
MEGA OFF mais ça me saoule*/

> LKoLRn : c'est un vieux topic, regarde les dates...

si personne ne répond c'est soit ils ne savent pas soit ça n'interesse personne.