En effet wild-D, le résultat n'est composé que de caractère en base 64. Je n'ai pas choisi le symbole /, c'est un caractère de la base 64 officielle.
J'aurais sans doute pu le remplacer par un autre, vous pouvez très bien la personnaliser
Mais, pour faire le lien avec votre exemple, j'ai créé cette fonction pour pouvoir passer le nom d'un fichier via la méthode GET sans que l'utilisateur (ou tout hackeur) puisse le connaître, il peut aussi servir pour passer des données dans un formulaire ou même envoyer un code par mail.

Au niveau de la cryptographie, il faut savoir que si vous pouvez le décoder, généralement un hackeur peut aussi le faire.
C'est pour cela que j'ai agrémenté le tout d'une chaîne clé afin de ne pas avoir qu'un algorithme qui peut être inversé.
Au départ, mon calcul décimal était trop simple, en effectuant un seul test en connaissant la chaîne d'entrée et la chaîne de sortie, on pouvait retrouver la clé. Logiquement, maintenant c'est impossible car j'y ai mêlé multiplication et addition à partir de la décomposition de la chaîne clé.

EDIT pour Anthor: Ouais mais faut lire la doc

J'utilise déjà les sessions dans la plupart de mes sites mais si je le fais, c'est que je n'ai pas le choix et que c'est le meilleur moyen.
Je ne poste pas pour que tu es à me dire ce que je dois faire ou pas, non mais !
Plus sérieusement, je ne peux pas utiliser les sessions sur des sites auxquels je n'ai pas accès. Ce sont des liens que je donnerai sur des sites extérieurs, donc les données ne sont pas locales alors aucun rapport avec les sessions.

Session ou non, je ne vois toujours pas l'intérêt par rapport a mcrypt ? les exemples donnés sont parfaitement utilisables, quel rapport avec la doc ?
Le premier n'est plus à utiliser mais fonctionne, le deuxième présente la nouvelle méthode depuis php5.2

(01-19-2009 11:57 PM)IGstaff a écrit :  J'utilise déjà les sessions dans la plupart de mes sites mais si je le fais, c'est que je n'ai pas le choix et que c'est le meilleur moyen.
Je ne poste pas pour que tu es à me dire ce que je dois faire ou pas, non mais !
Plus sérieusement, je ne peux pas utiliser les sessions sur des sites auxquels je n'ai pas accès. Ce sont des liens que je donnerai sur des sites extérieurs, donc les données ne sont pas locales alors aucun rapport avec les sessions.

heu en même temps le principe énoncé par oxman reste valable

si tu tiens à sécuriser des données pour éviter que le client y ai accès, autant ne pas les refiler au client (en clair ou cryptée) ! C'est du simple bon sens.

si tu ne peux passer par les sessions, le principe de base est toujours accessible : un stockage temporaire (bdd, fichier, que sais-je) permettant le lien entre une clé (arbitraire/aléatoire) et une donnée.

A la base la cryptographie: ça sert à transmettre des données entre 2 entités différentes en évitant que des intermédiaire puissent trop facilement y accéder. Quand l'émetteur et le récepteur sont la même entité, ça parait pas très cohérent...

justement, si j'ai bien compris, il en propose de l'utiliser que pour des échanges entre deux sites (donc deux entités)

(01-20-2009 05:56 PM)Ter Rowan a écrit :  justement, si j'ai bien compris, il en propose de l'utiliser que pour des échanges entre deux sites (donc deux entités)

nan il n'y a qu'une entité si j'ai bien compris sa dernière remarque

Citation :Mais, pour faire le lien avec votre exemple, j'ai créé cette fonction pour pouvoir passer le nom d'un fichier via la méthode GET sans que l'utilisateur (ou tout hackeur) puisse le connaître, il peut aussi servir pour passer des données dans un formulaire ou même envoyer un code par mail.

-> son site émet l'url avec un parametre crypté
->le lien est "publié/hébergé par un site tiers/transmis par un support intermédiaire autre que le site web"
->son site affiche "le contenu" demandé par le lien

l'émetteur et le récepteur sont la même entité

Anthor: Ca ne m'empeche pas de publier des ressources web, je ne vous oblige à rien.

L'utilisation d'une bdd serait inutilement lourd et ne servirait qu'à lier un fichier avec un ID.
Ce n'est pas ce qui m'intéresse ici.
Ces fonctions peuvent être très utiles et si vous n'en voyez pas l'utilité, ne les utilisez pas mais arrêtez de poster inutilement.

(01-22-2009 03:09 PM)IGstaff a écrit :  Ces fonctions peuvent être très utiles et si vous n'en voyez pas l'utilité, ne les utilisez pas mais arrêtez de poster inutilement.

Quand on poste des ressources, il faut s'attendre à être critiqué, positivement ou négativement. Et personnellement, je trouve les différentes interventions plutôt justifiées. Au lieu d'interdire aux gens de poster, tu pourrais peut-être donner un exemple typique où l'utilisation de ta ressource est pleinement justifiée.

Je pense que jusqu'ici personne n'a vraiment compris en quoi elle présentait de réels avantages par rapport à d'autres fonctions du core.

Je n'y connais rien en sécurité, en hacking, et en cryptage.
Mais j'aurai plutôt tendance a envoyer un éventuel hacker dans le mur en laissant l'url en clair, mais en y changeant le nom d'un répertoire.
Puis tu créer le répertoire de la fausse url et tu y met un htaccess

Comme tu lui donne une URL facilement, il va plutôt s'exciter a essayer de dégommer le htaccess (ça lui fait un os a ronger)


Moi je suis plus adepte de ce genre de magouille ca me fait marrer, et vu que c'est absolument pas conventionnel, je suppose que ça peut en emmerder un ou deux...

Bon évidement, ça repose sur le secret de la conversion du nom du répertoire.


Dans la même branche, je pense que ton système de cryptage si il est original a un fort potentiel de résistance, vu que personne ne le connais

Message qui n'a presque rien a voir mais n'oublie pas que si tu fait ton propre cryptage la loi Française (Si tu es Français) t'interdit tout cryptage avec une clé supérieur a 128bit, cela pour que le gouvernement puisse décrypter ton message en quelques minutes si besoin est tout en garantissant qu'un mec qui n'a pas de supercalculateur ne puisse casser ta clé.