JeromeJ's links
614 shaares
12 results
tagged
sebsauvage
Naviguant à travers mon code, je suis retombé là dessus. Design que je trouvais vraiment chouette. :P
Alors pour le coup j'ai décidé de changer le code pour qu'il s'affiche chaque année le 9 avril. C'est bien ça son anniv hein ? Hein ?
Alors pour le coup j'ai décidé de changer le code pour qu'il s'affiche chaque année le 9 avril. C'est bien ça son anniv hein ? Hein ?
Bon, sachant que sebsauvage lit rarement ses mails, je vais tenter de le contacter par ici. :)
Ton implémentation est non sécurisée. C'est mal car d'autres personnes risquent de s'en inspirer sans savoir les problèmes liés à cette implémentation.
1) " Warning - When comparing the output of hexdigest() to an externally-supplied digest during a verification routine, it is recommended to use the compare_digest() function instead of the == operator to reduce the vulnerability to timing attacks." https://docs.python.org/3.4/library/hmac.html#hmac.HMAC.hexdigest
2) "The digestmod argument to the hmac.new() function may now be any hash digest name recognized by hashlib. In addition, the current behavior in which the value of digestmod defaults to MD5 is deprecated: in a future version of Python there will be no default value. (Contributed by Christian Heimes in issue 17276.)" https://docs.python.org/3/whatsnew/3.4.html#hmac
Donc il faudrait mieux commencer à spécifier une valeur pour digestmod.
Comme suggéré par l'issue (1) et cette réponse sur SO (2), je proposerais d'utiliser SHA-256 ou SHA-512 comme suit :
hmac.compare_digest(hmac.new(key, name, digestmod=hashlib.sha256).hexdigest(), signature)
(+ remplacer partout où il faut bien sure et ne pas oublier import hashlib)
(1) https://bugs.python.org/issue17276
"As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.
Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too."
(2) http://crypto.stackexchange.com/a/9340/18518
"Yes, there are currently no known attacks on HMAC-MD5.
[…]
However, this does not mean you should use HMAC-MD5 in new cryptosystem designs. To paraphrase Bruce Schneier, "attacks only get better, never worse." We already have practical collision attacks for MD5, showing that it does not meet its original security goals; it's possible that, any day now, someone might figure out a way to turn those into a preimage attack, which would compromise the security of HMAC-MD5. A much better choice would be to use HMAC with a hash function having no known attacks, such as SHA-2 or SHA-3."
Ton implémentation est non sécurisée. C'est mal car d'autres personnes risquent de s'en inspirer sans savoir les problèmes liés à cette implémentation.
1) " Warning - When comparing the output of hexdigest() to an externally-supplied digest during a verification routine, it is recommended to use the compare_digest() function instead of the == operator to reduce the vulnerability to timing attacks." https://docs.python.org/3.4/library/hmac.html#hmac.HMAC.hexdigest
2) "The digestmod argument to the hmac.new() function may now be any hash digest name recognized by hashlib. In addition, the current behavior in which the value of digestmod defaults to MD5 is deprecated: in a future version of Python there will be no default value. (Contributed by Christian Heimes in issue 17276.)" https://docs.python.org/3/whatsnew/3.4.html#hmac
Donc il faudrait mieux commencer à spécifier une valeur pour digestmod.
Comme suggéré par l'issue (1) et cette réponse sur SO (2), je proposerais d'utiliser SHA-256 ou SHA-512 comme suit :
hmac.compare_digest(hmac.new(key, name, digestmod=hashlib.sha256).hexdigest(), signature)
(+ remplacer partout où il faut bien sure et ne pas oublier import hashlib)
(1) https://bugs.python.org/issue17276
"As of now the hash algorithm for HMAC defaults to MD5. However MD5 is considered broken. HMAC-MD5 is still ok but shall not be used in new code. Applications should slowly migrate away from HMAC-MD5 and use a more modern algorithm like HMAC-SHA256.
Therefore I propose that default digestmod should be deprecated in Python 3.4 and removed in 3.5. Starting with Python 3.5 developer are forced to choose a hash algorithm like SHA256. Our documentation shall suggest it, too."
(2) http://crypto.stackexchange.com/a/9340/18518
"Yes, there are currently no known attacks on HMAC-MD5.
[…]
However, this does not mean you should use HMAC-MD5 in new cryptosystem designs. To paraphrase Bruce Schneier, "attacks only get better, never worse." We already have practical collision attacks for MD5, showing that it does not meet its original security goals; it's possible that, any day now, someone might figure out a way to turn those into a preimage attack, which would compromise the security of HMAC-MD5. A much better choice would be to use HMAC with a hash function having no known attacks, such as SHA-2 or SHA-3."
Bronco: "Une petite idée d'amélioration possible pour pickypaste: serait-il possible d'étendre la durée de validité du message pour le user ? (ou de cocher une case "permettre au destinataire de prolonger la durée de validité")
ça permettrait de ne pas perdre direct le message si on n'a pas le temps d'y répondre dès la lecture ^^"
J'aime beaucoup l'idée (si je l'ai bien comprise), mais je ne vois pas trop (pas encore ?) comment on pourrait implémenter ça par contre…
(Le fait que PickyPaste utilise un zerobin externe au lieu d'être un fork de zerobin limite quelques possibilités ou rend les choses plus complexes...)
ça permettrait de ne pas perdre direct le message si on n'a pas le temps d'y répondre dès la lecture ^^"
J'aime beaucoup l'idée (si je l'ai bien comprise), mais je ne vois pas trop (pas encore ?) comment on pourrait implémenter ça par contre…
(Le fait que PickyPaste utilise un zerobin externe au lieu d'être un fork de zerobin limite quelques possibilités ou rend les choses plus complexes...)
J'avais au début penser à une simple info à rajouter dans le lien après l'ancre (avec la clé de déchiffrement) mais je pense qu'on peut mieux faire.
* En effet, voyez-vous, ça induit un problème :
Si j'envoie un lien "Burn After Reading" sur un réseau non fiable, disons par exemple Skype, mais que l'information sur quand il expire serait elle-même contenue dans l'URL.
Alors, le méchant réseau (ça pourrait très bien être chez vous, à votre boulot, etc. = tout ce qui n'est pas chiffré bout-à-bout) pourrait éventuellement récupérer cette date d'expiration et tenter de l'ouvrir juste avant expiration.
De cette manière si vous avez oublié de l'ouvrir, il peut aisément savoir le moment le plus propice pour l'ouvrir sans risquer de se faire chopper.
En effet il est très peu probable que vous parveniez à l'ouvrir entre le moment où il l'a ouvert et le moment où il a expiré, tout au plus, cela vous laisserait seulement avec un doute qu'il se peut qu'il y ait eu un lag ou que les horloges entre vous et le serveur soient un peu décalées mais qu'au final, dans tous les cas, vous êtes peut-être arrivé un peu trop tard (Fin bref ça reste quand même extrême).
* SOLUTION:
La solution serait, je pense, et afin de ne pas être obligé de garder la métadonnée (quand ce paste était censé expiré) même après suppression du contenu des pastes expiré (pour clean up) d'avoir une clée privée côté serveur et d'avoir l'information de quand le paste devait expiré chiffré dans l'URL du paste et envoyé au serveur lors de la tentative de récupération du paste. Alors, si le serveur ne peut pas servir ce paste, il déchiffre l'information stockée dans l'URL (seul lui le peut, car elle aura été chiffré par sa clé publique) et il affichera l'information.
De cette manière on garde la fonctionnalité sans donner un moyen facile pour un réseau espion d'exploiter une faille potentielle.
(Seule faiblesse que je vois c'est que la clé privée privée du serveur est unique, y aurait-il moyen de, plutôt, la lier à l'id du paste ?
Genre peut-on créer une paire de clé à partir de "salt du serveur (privé, unique) + id du past" qui servirait à chiffrer l'info de façon unique pour chaque paste ?)
* En effet, voyez-vous, ça induit un problème :
Si j'envoie un lien "Burn After Reading" sur un réseau non fiable, disons par exemple Skype, mais que l'information sur quand il expire serait elle-même contenue dans l'URL.
Alors, le méchant réseau (ça pourrait très bien être chez vous, à votre boulot, etc. = tout ce qui n'est pas chiffré bout-à-bout) pourrait éventuellement récupérer cette date d'expiration et tenter de l'ouvrir juste avant expiration.
De cette manière si vous avez oublié de l'ouvrir, il peut aisément savoir le moment le plus propice pour l'ouvrir sans risquer de se faire chopper.
En effet il est très peu probable que vous parveniez à l'ouvrir entre le moment où il l'a ouvert et le moment où il a expiré, tout au plus, cela vous laisserait seulement avec un doute qu'il se peut qu'il y ait eu un lag ou que les horloges entre vous et le serveur soient un peu décalées mais qu'au final, dans tous les cas, vous êtes peut-être arrivé un peu trop tard (Fin bref ça reste quand même extrême).
* SOLUTION:
La solution serait, je pense, et afin de ne pas être obligé de garder la métadonnée (quand ce paste était censé expiré) même après suppression du contenu des pastes expiré (pour clean up) d'avoir une clée privée côté serveur et d'avoir l'information de quand le paste devait expiré chiffré dans l'URL du paste et envoyé au serveur lors de la tentative de récupération du paste. Alors, si le serveur ne peut pas servir ce paste, il déchiffre l'information stockée dans l'URL (seul lui le peut, car elle aura été chiffré par sa clé publique) et il affichera l'information.
De cette manière on garde la fonctionnalité sans donner un moyen facile pour un réseau espion d'exploiter une faille potentielle.
(Seule faiblesse que je vois c'est que la clé privée privée du serveur est unique, y aurait-il moyen de, plutôt, la lier à l'id du paste ?
Genre peut-on créer une paire de clé à partir de "salt du serveur (privé, unique) + id du past" qui servirait à chiffrer l'info de façon unique pour chaque paste ?)
À la question de youpla sur la possibilité d'implémenter une validation par JavaScript pour les pastes de type "Burn After Reading":
" Salut, ce “problème” comme tu l'appelles est normal.
Il serait possible d'implémenter une confirmation par JavaScript mais ça serait fortement déconseillé. En effet, quelqu'un (un bot par exemple) pourrait très bien récupérer le message chiffré et tenter de le déchiffrer lui-même plus tard sans que personne ne remarque que cela a été fait : C'est contre le principe du “Burn after reading”, si quelqu'un l'a ouvert avant toi, tu dois le savoir !
Ceci dit, en y réfléchissant on pourrait implémenter un hack / une solution, qui consisterait à ne pas se rendre directement sur la page permettant de récupérer le message mais sur une page intermédiaire qui, elle, ferait une redirection JavaScript vers la bonne page. Cela permettrait que, si on a JavaScript désactivé (car on utilise NoScript par exemple) cela nous prévienne sans pour autant que cela invalide le paste.
On conserverait ainsi le but premier de “Burn after reading”, si quelqu'un se rend bel et bien sur la page du paste, c'est sûrement grâce au JavaScript (donc on ne risque plus de l'invalider accidentellement) mais si un bot s'y rend manuellement (sur la page donnant le paste, pas l'intermédiaire, celle là on s'en fout que le bot y passe limite), tu le saura.
(De plus, je trouve que de manière générale, à part le fait que ça rajoute une étape (lourde ?) ça permettrait de pouvoir partager des liens ZeroBin même sur les services connu pour aller zieuter la page automatiquement (comme Facebook ou un mauvais service qui s'amuserait à vérifier tout vos liens automatiquement)(sauf si évidemment, ils exécutent le JavaScript et vont voir où il ne devrait pas; c'est rarement le cas donc)) "
" Salut, ce “problème” comme tu l'appelles est normal.
Il serait possible d'implémenter une confirmation par JavaScript mais ça serait fortement déconseillé. En effet, quelqu'un (un bot par exemple) pourrait très bien récupérer le message chiffré et tenter de le déchiffrer lui-même plus tard sans que personne ne remarque que cela a été fait : C'est contre le principe du “Burn after reading”, si quelqu'un l'a ouvert avant toi, tu dois le savoir !
Ceci dit, en y réfléchissant on pourrait implémenter un hack / une solution, qui consisterait à ne pas se rendre directement sur la page permettant de récupérer le message mais sur une page intermédiaire qui, elle, ferait une redirection JavaScript vers la bonne page. Cela permettrait que, si on a JavaScript désactivé (car on utilise NoScript par exemple) cela nous prévienne sans pour autant que cela invalide le paste.
On conserverait ainsi le but premier de “Burn after reading”, si quelqu'un se rend bel et bien sur la page du paste, c'est sûrement grâce au JavaScript (donc on ne risque plus de l'invalider accidentellement) mais si un bot s'y rend manuellement (sur la page donnant le paste, pas l'intermédiaire, celle là on s'en fout que le bot y passe limite), tu le saura.
(De plus, je trouve que de manière générale, à part le fait que ça rajoute une étape (lourde ?) ça permettrait de pouvoir partager des liens ZeroBin même sur les services connu pour aller zieuter la page automatiquement (comme Facebook ou un mauvais service qui s'amuserait à vérifier tout vos liens automatiquement)(sauf si évidemment, ils exécutent le JavaScript et vont voir où il ne devrait pas; c'est rarement le cas donc)) "
Je trouve que les miniatures dans Shaarli devrait être mise en cache sur le serveur hébergeant ledit Shaarli plutôt que d'être systématiquement récupérée sur Youtube (ou autre) :/
En effet, ne s'agit-il pas là d'un mini-traqueur sûrement involontaire de ta part pour Youtube (ou autre) ? Les visiteurs de shaarli, informent donc, une fois de plus et sans vraiment s'en rendre compte, les informations qu'ils lisent et où ils sont sur le net et ce même sans ouvrir ledit lien vers une vidéo Youtube par exemple.
Suis pas fan du tout :/
EDIT: Apparemment il s'agirait du fait que certains sites sont rapides pour obtenir les thumbnails, d'autres pas. Ceux qui sont lents à obtenir sont mis en cache.
Perso je troque bien le temps pour stocker en cache + l'espace requis pour les thumbnails supplémentaires contre le respect de la vie privée supplémentaire que ça apporte.
Definitely.
EDIT: Success: http://shaarli.fr/index.php?q=les%20miniatures%20dans%20Shaarli
EDIT: Plus de réponses ici: http://shaarli.fr/index.php?q=Shaarli%20et%20ses%20dr%C3%B4les%20de%20miniatures%20?
Perso, je serais pour l'intégration de Respawn avec une ptite case à cochée lorsqu'on rajoute un lien et contre l'utilisation d'un service tiers pour la génération de webshot (sauf via une option ptet).
Par contre, quel liens serait affiché alors ? L'authentique ou la version stockée Respawn ? S'il ne s'agit "que" d'une page web, Respawn peut parfois être plus intéressant, même s'il ne s'adapte pas dynamiquement - de toutes façons les pages sont souvent statiques, au cas où la page disparaîtrait du net. Alors que pour certains types de fichiers volumineux il vaut peut-être mieux donner le lien authentique pour éviter de tuer la bande passante si on a pas un gros site (mais ça serait quand même chouette de pouvoir l'enregistrer au choix via une case à cocher, comme ça si le lien est mort, donner le lien local vaut ptet mieux.
J'sais pas ... à voir. Sûrement une question de juste milieux.
En effet, ne s'agit-il pas là d'un mini-traqueur sûrement involontaire de ta part pour Youtube (ou autre) ? Les visiteurs de shaarli, informent donc, une fois de plus et sans vraiment s'en rendre compte, les informations qu'ils lisent et où ils sont sur le net et ce même sans ouvrir ledit lien vers une vidéo Youtube par exemple.
Suis pas fan du tout :/
EDIT: Apparemment il s'agirait du fait que certains sites sont rapides pour obtenir les thumbnails, d'autres pas. Ceux qui sont lents à obtenir sont mis en cache.
Perso je troque bien le temps pour stocker en cache + l'espace requis pour les thumbnails supplémentaires contre le respect de la vie privée supplémentaire que ça apporte.
Definitely.
EDIT: Success: http://shaarli.fr/index.php?q=les%20miniatures%20dans%20Shaarli
EDIT: Plus de réponses ici: http://shaarli.fr/index.php?q=Shaarli%20et%20ses%20dr%C3%B4les%20de%20miniatures%20?
Perso, je serais pour l'intégration de Respawn avec une ptite case à cochée lorsqu'on rajoute un lien et contre l'utilisation d'un service tiers pour la génération de webshot (sauf via une option ptet).
Par contre, quel liens serait affiché alors ? L'authentique ou la version stockée Respawn ? S'il ne s'agit "que" d'une page web, Respawn peut parfois être plus intéressant, même s'il ne s'adapte pas dynamiquement - de toutes façons les pages sont souvent statiques, au cas où la page disparaîtrait du net. Alors que pour certains types de fichiers volumineux il vaut peut-être mieux donner le lien authentique pour éviter de tuer la bande passante si on a pas un gros site (mais ça serait quand même chouette de pouvoir l'enregistrer au choix via une case à cocher, comme ça si le lien est mort, donner le lien local vaut ptet mieux.
J'sais pas ... à voir. Sûrement une question de juste milieux.
Not bad!
Je me demande si cette technique et/ou tout simplement le système de discussion pourrait être utilisé dans PickyPaste d'une façon ou d'une autre … Mmmh.
Les possibilités sont très certainement nombreuses et variées mais si on voudrait faire des discussions chiffrés très facilement, en étant directement informé par mail (plus simpatoche et accessible non ?) ce qui serait à limite le plus simple serait ptet de patcher un zérobin pour que chaque réponse envoyée envoie un mail associé … Mmmmh (<- Bruit d'intense réflexion)
(via http://ithake.eu/shaarli/?iq64Fw )
Je me demande si cette technique et/ou tout simplement le système de discussion pourrait être utilisé dans PickyPaste d'une façon ou d'une autre … Mmmh.
Les possibilités sont très certainement nombreuses et variées mais si on voudrait faire des discussions chiffrés très facilement, en étant directement informé par mail (plus simpatoche et accessible non ?) ce qui serait à limite le plus simple serait ptet de patcher un zérobin pour que chaque réponse envoyée envoie un mail associé … Mmmmh (<- Bruit d'intense réflexion)
(via http://ithake.eu/shaarli/?iq64Fw )
Ajout de 2 fonctionnalités à PickyPaste :
1) PickyPaste, jusqu'à présent, retirait une des fonctionnalités de Zerobin, la possibilité de supprimer son paste manuellement. J'ai donc rajouter ce lien sur la page de confirmation que tout s'est bien déroulé. (TODO: En cas d'échec de l'envoie du mail, supprimer le paste automatiquement ?)
2) Début d'implémentation de la fonctionnalité à laquelle sebsauvage n'a pas (pas encore ?) répondu.
Vous pouvez voir ma proposition ici: http://sebsauvage.net/wiki/doku.php?id=php:zerobin_discussion#comment_2316c22761c0c17c2b7785d2f0d4fc2e
Actuellement, ça affiche la date d'expiration du message ainsi qu'une explication et ce à fin d'aider à déterminer, si lorsqu'on tente d'ouvrir le message celui-ci n'existe plus alors qu'il s'agissait d'un message à lecture unique, si cela est bien dût à une expiration "naturelle" ou si on a des raisons de s'inquiéter que le raison est peut-être corrompu (expiration anormale).
Auparavant, vous n'aviez que l'embarras du doute et généralement on finit par penser que c'est sûrement peut-être de notre faute (ouverture trop tardive) et on perd la possibilités de savoir si le réseau est corrompu.
Lien vers PickyPaste : http://www.olissea.com/PickyPaste/
Lien vers mon shaarlink sur PickyPaste : http://www.olissea.com/mb/links/1/?rI8PbQ
1) PickyPaste, jusqu'à présent, retirait une des fonctionnalités de Zerobin, la possibilité de supprimer son paste manuellement. J'ai donc rajouter ce lien sur la page de confirmation que tout s'est bien déroulé. (TODO: En cas d'échec de l'envoie du mail, supprimer le paste automatiquement ?)
2) Début d'implémentation de la fonctionnalité à laquelle sebsauvage n'a pas (pas encore ?) répondu.
Vous pouvez voir ma proposition ici: http://sebsauvage.net/wiki/doku.php?id=php:zerobin_discussion#comment_2316c22761c0c17c2b7785d2f0d4fc2e
Actuellement, ça affiche la date d'expiration du message ainsi qu'une explication et ce à fin d'aider à déterminer, si lorsqu'on tente d'ouvrir le message celui-ci n'existe plus alors qu'il s'agissait d'un message à lecture unique, si cela est bien dût à une expiration "naturelle" ou si on a des raisons de s'inquiéter que le raison est peut-être corrompu (expiration anormale).
Auparavant, vous n'aviez que l'embarras du doute et généralement on finit par penser que c'est sûrement peut-être de notre faute (ouverture trop tardive) et on perd la possibilités de savoir si le réseau est corrompu.
Lien vers PickyPaste : http://www.olissea.com/PickyPaste/
Lien vers mon shaarlink sur PickyPaste : http://www.olissea.com/mb/links/1/?rI8PbQ
Ça y est !!!! :D
Enfin ! Au final, j'ai eu bien plus de difficultés que prévu, d'où mes cris de joies :'D #seulLesCodeursPeuventComprendre
Zerobin ? Facile à utiliser ? FOOL!! Fin moi aussi je le pensais … Jusqu'à ce que ma route croise quelques néophytes du web :/ … J'ai encore mal !
Il fallait encore plus simple ! Un no-brainer, clique clique, pesé c'est envoyé !
(En gardant toujours le tout highly paramétrable tant qu'on a une option par défaut c'est ce qui compte ET libre (open source, toussa, etc))
Boum: PickyPaste, based on Zerobin's core, that's for PickyPeople who wants robustness (yeay Zerobin) AND super-easy-to-use. DONE!
Le but de l'appli est surtout de pouvoir l'utiliser via le snippet: Une page intéressante que j'aimerais partager ? Alors faut quelque chose d'aussi simple que le traditionnel bouton Partager, sinon les gens ne verront aucune raison à ce qu'ils se cassent le cul à devoir faire des trucs en plus compliqués.
Alors on leur donne juste un favoris à cliquer dessus, hop, ça ouvre un nouvel onglet avec le message préremplis avec l'adresse de la page où on se trouvait.
On rentre l'email du destinataire (pourra y avoir une liste par défaut plus tard, genre se faire une liste de contact et tout, mais tout en restant KISS) (et ça sera aussi facilement modulable, donc le choix de l'email n'est pas forcé) ainsi que le sien si on veut pouvoir être répondu,
Les autres options ont toutes une valeur par défaut (avec une ptite explication quand au fonctionnement du "BurnAfterReading" activé par défaut), les options classiques de Zerobin sont toutes là, mais on peut également préciser un serveur Zerobin alternatif ou un serveur mail alternatif (car plus tard, il est prévu de pouvoir avoir le client sur son pc, en .html pour éviter contre une prise de domaine).
Le mail envoyé comporte une petite explication sommaire du pourquoi et du comment et utilise l'entête Reply-To si l'adresse email fournie est valide.
Le code source de l'app est disponible en bas de la page :)
Next to come: The English version (and a lot of other stuff)
PS: Bon, ne faites pas trop attention au design hein :p c'pas mon fort :3
Sujet lié: http://www.olissea.com/bbs/?tid=962
Enfin ! Au final, j'ai eu bien plus de difficultés que prévu, d'où mes cris de joies :'D #seulLesCodeursPeuventComprendre
Zerobin ? Facile à utiliser ? FOOL!! Fin moi aussi je le pensais … Jusqu'à ce que ma route croise quelques néophytes du web :/ … J'ai encore mal !
Il fallait encore plus simple ! Un no-brainer, clique clique, pesé c'est envoyé !
(En gardant toujours le tout highly paramétrable tant qu'on a une option par défaut c'est ce qui compte ET libre (open source, toussa, etc))
Boum: PickyPaste, based on Zerobin's core, that's for PickyPeople who wants robustness (yeay Zerobin) AND super-easy-to-use. DONE!
Le but de l'appli est surtout de pouvoir l'utiliser via le snippet: Une page intéressante que j'aimerais partager ? Alors faut quelque chose d'aussi simple que le traditionnel bouton Partager, sinon les gens ne verront aucune raison à ce qu'ils se cassent le cul à devoir faire des trucs en plus compliqués.
Alors on leur donne juste un favoris à cliquer dessus, hop, ça ouvre un nouvel onglet avec le message préremplis avec l'adresse de la page où on se trouvait.
On rentre l'email du destinataire (pourra y avoir une liste par défaut plus tard, genre se faire une liste de contact et tout, mais tout en restant KISS) (et ça sera aussi facilement modulable, donc le choix de l'email n'est pas forcé) ainsi que le sien si on veut pouvoir être répondu,
Les autres options ont toutes une valeur par défaut (avec une ptite explication quand au fonctionnement du "BurnAfterReading" activé par défaut), les options classiques de Zerobin sont toutes là, mais on peut également préciser un serveur Zerobin alternatif ou un serveur mail alternatif (car plus tard, il est prévu de pouvoir avoir le client sur son pc, en .html pour éviter contre une prise de domaine).
Le mail envoyé comporte une petite explication sommaire du pourquoi et du comment et utilise l'entête Reply-To si l'adresse email fournie est valide.
Le code source de l'app est disponible en bas de la page :)
Next to come: The English version (and a lot of other stuff)
PS: Bon, ne faites pas trop attention au design hein :p c'pas mon fort :3
Sujet lié: http://www.olissea.com/bbs/?tid=962
Aah vous avez de la chance :)
Z'allez sûrement rencontré des fans ^^ lol :p Vous nous raconterez :D
Moi je ne saurais pas malheureusement ! Mais si l'occasion se représente pour un verre, ça sera volontiers, héhé.
Z'allez sûrement rencontré des fans ^^ lol :p Vous nous raconterez :D
Moi je ne saurais pas malheureusement ! Mais si l'occasion se représente pour un verre, ça sera volontiers, héhé.
Ah bon on peut passer par son compte Google à la place ? Moi j'utilise les flux RSS youtube tous les jours :)
Ma vie a changé depuis que j'ai découvert ça :p
Ma vie a changé depuis que j'ai découvert ça :p
Ça y est, "à cause" de KrISS Feed, je suis (du verbe suivre) enfin activement le flux de lien en vrac de sebsauvage, il poste de trooooooop :(
J'vais pas m'en plaindre mais voilà, avant j'allais seulement le consulter de temps à autres :p maintenant il est toujours là à me solliciter ^^
Donc excusez-moi si je reshaarlink de plus en plus de stuff provenant de sebsauvage :) Mon shaarli me sert aussi de favoris.
J'vais pas m'en plaindre mais voilà, avant j'allais seulement le consulter de temps à autres :p maintenant il est toujours là à me solliciter ^^
Donc excusez-moi si je reshaarlink de plus en plus de stuff provenant de sebsauvage :) Mon shaarli me sert aussi de favoris.