(Pas de soucis, c'est justement le genre de solution que je voulais entendre & découvrir, sans forcément me jeter dessus 
)
Ca m'embête un peu quand même, ce concept d'avoir une clef pour toute l'appli, surtout quand l'utilisateur maîtrise les données à chiffrer (genre pseudo ou email). Et si on la renouvelle, soit on invalide toutes les sessions, soit on traîne encore de la complexité en gérant l'ancienne et la nouvelle clef pendant un temps.
Dans ce cas, cela implique d'avoir un appel BDD à chaque fois, et de stocker des tokens (ce qui revient à peu près à un système de session et retire l'aspect stateless, non?!).
Il y a aussi la fiabilité du bazar car la couche native a souvent plus de dev & bien plus d'utilisateurs que les couches suppérieures (qui, également, doivent suivre les évolution du natif et être compatibles). Bon, après, je trouve aussi que bien trop de FW viennent souvent avec bien trop de dépendances derrière, donc si on veut y foutre les pieds, on s'y enfonce jusqu'au cou.
L'avantage tout de même du cookie de session, c'est qu'on ne peut pas le crafter en local et l'analyser. Un cookie stateless, par définition, je peux le disséquer autant que je veux en local (et donc, cela pourrait ouvrir la porte à des attaques). Bon, sur un JW, les conséquences, osef un peu. Hmm en quoi cela donne "plus" de contrôle? Cela en donne un différent: je peux donner une durée de vie à cette session, mais je ne peux pas facilement lister les sessions et en invalider une; je peux faire du stateless, mais je ne peux pas stocker la planète dedans (pas au delà de quelques Ko, et franchement, c'est déjà énorme [ok, c'est théorique, j'ai pas besoin de stocker des tonnes de trucs]).
'fin bon, c'est intéressant comme solution, mais je n'ai pas envie de passer du temps à la mettre en place, donc si elle apparait magiquement dans PHP, je m'y intéresserai. Sinon, tant pis!
PS: comment se nomme le concept en Anglais? J'ai un mal de chien à le trouver...
)Ca m'embête un peu quand même, ce concept d'avoir une clef pour toute l'appli, surtout quand l'utilisateur maîtrise les données à chiffrer (genre pseudo ou email). Et si on la renouvelle, soit on invalide toutes les sessions, soit on traîne encore de la complexité en gérant l'ancienne et la nouvelle clef pendant un temps.
Dans ce cas, cela implique d'avoir un appel BDD à chaque fois, et de stocker des tokens (ce qui revient à peu près à un système de session et retire l'aspect stateless, non?!).
Il y a aussi la fiabilité du bazar car la couche native a souvent plus de dev & bien plus d'utilisateurs que les couches suppérieures (qui, également, doivent suivre les évolution du natif et être compatibles). Bon, après, je trouve aussi que bien trop de FW viennent souvent avec bien trop de dépendances derrière, donc si on veut y foutre les pieds, on s'y enfonce jusqu'au cou.
L'avantage tout de même du cookie de session, c'est qu'on ne peut pas le crafter en local et l'analyser. Un cookie stateless, par définition, je peux le disséquer autant que je veux en local (et donc, cela pourrait ouvrir la porte à des attaques). Bon, sur un JW, les conséquences, osef un peu. Hmm en quoi cela donne "plus" de contrôle? Cela en donne un différent: je peux donner une durée de vie à cette session, mais je ne peux pas facilement lister les sessions et en invalider une; je peux faire du stateless, mais je ne peux pas stocker la planète dedans (pas au delà de quelques Ko, et franchement, c'est déjà énorme [ok, c'est théorique, j'ai pas besoin de stocker des tonnes de trucs]).
'fin bon, c'est intéressant comme solution, mais je n'ai pas envie de passer du temps à la mettre en place, donc si elle apparait magiquement dans PHP, je m'y intéresserai. Sinon, tant pis!
PS: comment se nomme le concept en Anglais? J'ai un mal de chien à le trouver...