Ils sont sympas sur le tchat PHP de SO.

Quelques amis m'ont donné des exemples de codes à propos des exceptions en PHP, que j'ai, un peu trop souvent rechigné.

C'est *bô*. Jugez-en par vous même:

http://3v4l.org/NJJjO

function （╯°□°）╯︵┻━┻(){throw new ┻━┻;}
class ┻━┻ extends  Exception {public function __construct() {parent::__construct("Please respect tables! ┬─┬ノ(ಠ_ಠノ)");} public function __toString(){return "┬─┬";}}
// try/catch
try { （╯°□°）╯︵┻━┻ (); } catch ( ┻━┻ $niceguy) {echo $niceguy->getMessage();}
// ok now lets see an uncaught one
（╯°□°）╯︵┻━┻
();

// Output:
Please respect tables! ┬─┬ノ(ಠ_ಠノ)
Fatal error: Uncaught ┬─┬


Et http://3v4l.org/TkNpc

class JeromeException extends Exception
{
    protected $boobies = [];
   
    function __construct($message = null, $code = 0, Exception $previous = null, $arrayOfBoobies = [])
    {
        $this->boobies = $arrayOfBoobies;
    }
   
    function getTraceEx()
    {
        return $this->getTrace() + ['boobies' => $this->boobies];
    }
}

function jeromeIsExceptional()
{
    try {
        throw new JeromeException('herro', 0, null, ['34B', '32C', '36D']);
    }
    catch (JeromeException $e) {
        var_dump($e->getTraceEx());
    }
}

jeromeIsExceptional();

J'avais commencé par faire le tout avec GreaseMonkey mais j'ai eu des probs avec le setTimeout tué par GreaseMonkey.

Du coup, j'ai fais un code très rapide en PHP; Il est fonctionnel (c'était le but).

Mais pour MEGA, le téléchargement coince à la fin, sûrement un prob de compatibilité du au domaine différent (127.0.0.1 dans mon cas).
Du coup Oros m'a aidé à résoudre le problème GreaseMonkey - je n'ai toujours pas compris pourquoi son code fonctionne et pas le mien, … mais au moins son code fonctionne! :

window.setTimeout('function wait() {if(document.getElementsByClassName("new-download-red-button").length==0){setTimeout("wait()",1000);}else{document.getElementsByClassName("new-download-red-button")[0].click();}}wait();', 1000);

Source: https://www.ecirtam.net/links/?XoFKOQ

Ça pourrait sûrement très facilement être entièrement porté à GreaseMonkey du coup …

Pour finir, dans mon cas, pour que ça reste quand même "pratique" (car au moins avec greaseMonkey, aucun clic requis), j'ai, personnellement, tout plein de pages bourrées de ces liens, donc j'ai un quick snippet pour changer tous les liens de la page pour qu'ils passent tous via mon script, et lorsqu'un cas n'est pas géré, mon script redirige vers la page normal.

javascript:var%20links=document.getElementsByTagName('a');for(var%20i%20=%200;%20i%20<%20links.length;%20i++){void(links[i].href%20=%20'http://127.0.0.1/test.php?url='+links[i].href);}

Lien précédent : http://www.olissea.com/mb/links/1/?ibR8_g

EDIT: J'ai trouvé ce problème ceci dit: https://bugs.php.net/bug.php?id=65045
Mais j'ignore si je suis vraiment concerné : ça dépend en effet si mon script capture ces séquences à problèmes mais il me semble qu'il ne capture que les séquences valides de 4 bytes, donc pas de problème normalement.

Également, j'ai pas trop compris comment ça se fait, mais lorsque j'applique htmlspecialchars sur les séquences données sur la page, l'output n'est pas vide. Ne devrait-il pas l'être (vu que htmlspecialchars renvoie stupidement une chaîne vide lorsqu'il reçoit de l'UTF-8 invalide normalement ?).

Mmmmmh.
</EDIT>

"Plop.

Après mainte péripéties et échecs, je pense avoir trouver quelque chose de "potable".

Voir le code avec coloration syntaxique (un peu différent, manque une source) : http://sebsauvage.net/paste/?e249576d75ee9946#jBpv2UCufTQ4UC2WnTtM11gfolfGkQi61brf11pFORU=

<?php

# "😒" est codé sur 4 bytes
$body = 'lol😒a☺';

echo 'before: ',$body,'<br />'; # Output: lol😒a☺
echo 'length: ',strlen($body),'<br />'; # Output: 11 (😒 = 4, ☺ = 3)

# Le but est de remplacer uniquement les caractères de plus de 3 bytes par leur entité HTML.
# Afin d'obtenir ce code dans le cas de notre exemple
echo '😒','<br />'; # Fourni par https://duckduckgo.com/?q=html+%F0%9F%98%92

# Récupération des caractères de plus de 3 bytes uniquement
# Source: http://stackoverflow.com/a/1401716/1524913
# $body = preg_replace('/[\xF0-\xF7][\x80-\xBF]{3}/', '�', $body); # Yeah! It works!

# Ne fonctionne pas. htmlentities ne connaît pas tous les caractères unicode ( http://stackoverflow.com/a/13942507/1524913 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return htmlentities($m[0], ENT_COMPAT, 'UTF-8');}, $body); # Ignore complètement 😒

# La solution proposée au lien précédemment cité : Ne fonctionne pas non plus
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return str_replace('\\u','&#x',trim(json_encode($m[0]),'"')).';';}, $body);
# Output: lol��a☺ car json_encode considère ça comme deux caractères de deux bytes et renvoie "\ud83d\ude12"

# Ne fonctionne pas ( http://php.net/manual/en/function.htmlentities.php#107985 )
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_encode_numericentity($m[0], array(0x0, 0xffff, 0, 0xffff), 'UTF-8');}, $body); # Ignore complètement 😒

# Fonctionne !!! Mais renvoie &#128530 au lieu de 😒 (Pas vraiment un problème en soit)
# $body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8');}, $body);

# Si on veut vraiment la version hexadécimal
$body = preg_replace_callback('/[\xF0-\xF7][\x80-\xBF]{3}/', function($m){return '&#x'.dechex(substr(mb_convert_encoding($m[0], 'HTML-ENTITIES', 'UTF-8'), 2)).';';}, $body);

echo 'after: ',$body,'<br />'; # Output: lol😒a☺

?> "

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...)

J'essaie de trouver quelle serait la meilleure utilisation de htmlspecialchars si on ne possède pas encore PHP 5.4 (contraintes techniques).

D'une part, par défaut, si vous passez une chaîne contenant de l'UTF-8 invalide, htmlspecialchars vous retournera une chaîne complètement vide. ("Pratique")
Pour remédier à ça, il vous faut utiliser ENT_IGNORE ou ENT_SUBSTITUTE. ........ MAIS la doc déconseille l'utilisation de ENT_IGNORE pour des raisons de sécurité. ( http://unicode.org/reports/tr36/#Deletion_of_Noncharacters )
(Source: http://stackoverflow.com/q/11088953/1524913 )

Seulement voilà, ENT_SUBSTITUE est uniquement disponible à partir de PHP 5.4.0. (Donc je fais quoi… ?)

Notez égaaaaaaalement qu'il est impossible de spécifier les paramètres par défaut de htmlspecialchars et qu'il vaudrait mieux donc que vous créez votre propre wrapper.

Puis j'ai également trouvé cette perle … jugez par vous-même. ._."

"Error handling in htmlspecialchars before PHP 5.4 was … uhm, let’s call it “unintuitive”:

If you passed a string containing an “invalid code unit sequence” (which is Unicode slang for “not encoded correctly”) htmlspecialchars would return an empty string. Well, okay, so far so good. The funny thing was that it additionally would throw an error, but only if error display was disabled. So it would only error if errors are hidden. Nice, innit?"
(Source: http://nikic.github.io/2012/01/28/htmlspecialchars-improvements-in-PHP-5-4.html)

Cette page-ci n'est pas mal non plus: http://stackoverflow.com/q/13745353/1524913

Flask ne semble pas supporter la possibilité de retourner des générateurs comme WSGI peut le faire et je ne suis pas sûr qu'ils prévoient que ça soit le cas un jour … ( voir  https://github.com/mitsuhiko/flask/pull/684 )

Mais bon perso je trouve ça super sympa de pouvoir yield du contenu lorsqu'on veut dans son code. Un peu comme je pouvais le faire avec cgi ou en PHPouet.
De plus je suis entrain de migrer d'un code pur WSGI à Flask (sous les conseils de Link Mauve si je ne me méprend pas) - pour l'instant j'en suis toujours à l'étape "c'est relou". Pourvu que ça ne dure pas -, du coup c'est plus sympa pour moi de pouvoir conserver cette façon là.

(Note: J'avais également pas envie de devoir spécifier un décorateur @generator pour toutes mes fonctions contenant un yield, j'ai donc décidé de décorer app.route directement (mais ce fut un peu plus compliqué à mettre en place))

from functools import wraps

from flask import Flask, Response, stream_with_context

app = Flask(__name__)

# Decorator to make Flask accept generators

@wraps(app.route)
def route_accept_generators(*args, **kwargs):
route = route_accept_generators.app_route(*args, **kwargs)  # Getting our route decorator.

# Decorating it.
@wraps(route)
def decorated(f):

# Make so that the function that will be called return a valid Flask answer in case of returning a generator.
@wraps(f)
def function_accept_generators(*args, **kwargs):
r = f(*args, **kwargs)

if isinstance(r, types.GeneratorType):
# return Response(r, direct_passthrough=True)  # Solution proposed here: http://flask.pocoo.org/mailinglist/archive/2010/11/3/using-yield/#478b0c1829b5263700da1db7d2d22c79
return Response(stream_with_context(r))  # Solution found here: http://stackoverflow.com/q/13386681/1524913

return r

return route(function_accept_generators)

return decorated

# Store the function so that it doesn't make an infinite recursion call
# Because accessing from app.route rather than directly)
# And storing it in itself instead of creating another standalone variable
route_accept_generators.app_route = app.route

app.route = route_accept_generators

Lolilol PHP !

Allez ! On continue dans notre série "PHP c'est vraiment n'importe quoi !".

#poop, une faille XSS built-in. Une !
Afficher les erreurs en prod, c'est mal ? Non, c'est bien pire que ça ! C'est exposer son site à des failles XSS. Enjoy cette merde.

Pfff

https://bugs.php.net/bug.php?id=55139

Et évidemment, le plus beau c'est qu'ils ne veulent pas réparer ça, c'est pas un bug selon eux.
Si tu affiches les erreurs, alors tu renonces à la sécurité, selon eux.
(Ça leur fendrait trop le cul d'ajouter un htmlspeacialchars ? Genre …)
Bon, ok, on peut log les erreurs même en dev, mais de là à être obligé (faut-il encore le savoir que c'est dangereux à ce point)…

Même en dev, je pourrais extraire des données utilisateur d'un site externe et me faire piéger par un beau script JavaScript.

Bande de cons. -.-

Voilà ma version, j'en suis plutôt satisfait :

As PHP doesn't really have a proper alternative to str.format in Python, I decided to implement my very simple own which as most of the basic functionnalitites of the Python's one.

function format($msg, $vars)
{
    $vars = (array)$vars;

    $msg = preg_replace_callback('#\{\}#', function($r){
        static $i = 0;
        return '{'.($i++).'}';
    }, $msg);

    return str_replace(
        array_map(function($k) {
            return '{'.$k.'}';
        }, array_keys($vars)),

        array_values($vars),

        $msg
    );
}

# Samples:

# Hello foo and bar
echo format('Hello {} and {}.', array('foo', 'bar'));

# Hello Mom
echo format('Hello {}', 'Mom');

# Hello foo, bar and foo
echo format('Hello {}, {1} and {0}', array('foo', 'bar'));

# I'm not a fool nor a bar
echo format('I\'m not a {foo} nor a {}', array('foo' => 'fool', 'bar'));

1.    The order doesn't matter,
2.    You can omit the name/number if you want it to simply increment (the first {} matched will be transformed into {0}, etc),
3.    You can name your parameters,
4.    You can mix the three other points.

Pratique !