Besoin d'aide ?

Problème de formulaire dans ma vue

  • Avatar de L
    Membre depuis :
    21/07/2017
    Messages :
    20

    Bonjour,
    je suis nouvelle dans ce forum donc je ne suis pas sûre que ce soit l'endroit où poster ce message..
    Pour mon stage je dois reprendre un projet commencé l'année dernière mais j'ai un problème au niveau de ma vue. J'ouvre un formulaire avec {{ Form::open(['route' => 'portal.feedback', 'method' => 'POST', 'id' => 'form-questions-page-feed']) }} puis je le ferme avec {{ Form::close() }}.
    J'ai du code entre ces deux lignes et tout est inclus dans les balises

    sur le html généré sauf ma dernière ligne: {!! Form::submit(app('translator')->get('portal.submit'), ['class' => 'btn btn-primary', 'id' => 'submit-btn']) !!}.
    Je ne comprends pas pourquoi.. Pourriez vous m'aider s'il vous plaît ?

    Voici mon code :

    @extends('portal.index')

    @section('content-index')

    <div class="panel panel-default" style="padding-left:5%; padding-right:5%;">
    <div class="panel-body">
    <?php
    $feedback = Session::get('feedback');

    ?>

    {{ Form::open(['route' => 'portal.feedback', 'method' => 'POST', 'id' => 'form-questions-page-feed']) }}

    <center>

    @if(Session::has('not_completed'))
    <br>
    <div class="alert alert-danger alert-dismissible" id="msg-error-form-questions"><strong>{{ Session::pull('not_completed') }}</strong></div>
    @endif
    <h1><strong>{{ $feedback['name_form'] }}</strong></h1><br>
    </center>

    {{ Form::text('id_feedback', $feedback['id_feedback'], ['class' => 'hidden'])}}
    {{ Form::text('page', $idPage, ['class' => 'hidden'])}}
    {{ Form::text('new_page-feed', null, ['class' => 'hidden'])}}
    {{ Form::text('auto-feed', 'false', ['class' => 'hidden'])}}

    <div style="margin:auto; max-width:50%; width:auto;">
    <h2 id="name-section"><strong>Feedback</strong></h2><br>
    <div id='questions-feedback'>
    @foreach($feedback['pages'][$idPage]['questions'] as $key => $question)
    @include('portal.template_questions.'.$question['type_question'], $question)<br>
    @endforeach
    </div><br><br>
    </div>

    <center>
    {!! Form::submit(app('translator')->get('portal.submit'), ['class' => 'btn btn-primary', 'id' => 'submit-btn']) !!}
    </center>

    {{ Form::close() }}

    </div>

    </div>

    @include('portal.js_feedback')

    @stop
  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1461

    Bonjour,

    C'est quelle version de Laravel (on trouve ça dans composer.json) ?

  • Avatar de L
    Membre depuis :
    21/07/2017
    Messages :
    20

    C'est Laravel en version 5.2

  • Avatar de L
    Membre depuis :
    21/07/2017
    Messages :
    20

    problème résolu, j'airemplacé par {!! Form::close !!}. Je ne comprends quand même pas pourquoi ça ne marchait pas avec la première version..

  • Avatar de MakChan
    Membre depuis :
    24/05/2017
    Messages :
    6

    {!! quelquechose !!} au lieu de la double accolade permet, il me semble, de mieux gérer un "quelquechose" contenant du code HTML :) !

    {!! Form::close !!} générant un beau </form> HTML, c'est mieux de le mettre dans le bon cadre, surtout que ta fâmeuse dernière ligne s'y trouve bien également ! ({!! Form::submit(app('translator').....)

    Idéalement, il faudrait "cadré" correctement tes {{ Form::open ..., {{ Form::text..., etc.
    Ca ne change rien aux fonctionnalités, mais c'est plus uniforme et ça évite parfois les incompatiblités du genre de celle que tu à rencontré :) !

  • Avatar de L
    Membre depuis :
    21/07/2017
    Messages :
    20

    Merci pour votre réponse !
    Si je comprends bien, pour que je sois sûre que mes balises soient placées au bon endroit il faut que je mette partout des {!! à la place des {{ ?

  • Avatar de MakChan
    Membre depuis :
    24/05/2017
    Messages :
    6

    Je suis convaincu d'avoir lu quelque part que les {!! sont préférables en cadre de code HTML ...
    Donc ne pas remplacer les {{ partout mais bien sur des champs de code HTML du genre d'un </form> devenu{!! Form::close !!} !

    Imaginons qu'un site Web traite la donnée d'une vue ... Comme par exemple le prénom de l'Utilisateur (où autre).

    Ce prénom, cette donnée, n'as pas de contenu HTML, n'as pas de balises quoi, et peut donc (DOIT donc ?) se retrouver entre double accolades.

    Encore une fois c'est ma logique hein suivant l'idée qu'un {!! cadre avant tout de belles balises HTML :P.
    Ce n'est peut-être pas la vraie vérité ..

    Un p'ti exemple tiré de Blade lui même parle mieux que des mots j'imagine ..
    Alors on à une Route pour créer une Vue avec un Prenom en Paramètres :

    Route::get('greeting', function () {
    return view('welcome', ['prenom' => 'Samantha']);
    });

    Et la vue en question, affichant une salutation, suivie d'un formulaire :

    <p>Salut, {{ $prenom }} ! Dites nous votre nom de famille :</p>
    <br />
    {!! Form::open(['url' => 'users']) !!}
    {!! Form::label('nom', 'Entrez votre nom : ') !!}
    {!! Form::text('nom') !!}
    {!! Form::submit('Envoyer !') !!}
    {!! Form::close() !!}

    Où on à bien un cadre {{ pour la donnée et {!!pour la generation d'HTML.

    PAR CONTRE, après recherches plus approfondies j'apprends que les doubles quotes {{ disposent d'un filtre specialchars protégeant des attaques de type XSS.
    Et {!!n'est que le code pour contourner cette protection.

    Blade {{ }} statements are automatically sent through PHP's htmlspecialchars function to prevent XSS attacks.

    [...]

    If you do not want your data to be escaped, you may use the following syntax:

    Hello, {!! $name !!}.

    Si je viens de parler Chinois, puis Anglais, je m'en excuse et m'explique donc ^^ :

    1°- Une attaque XSS c'est le fait de pouvoir placer du code malveillant dans un input.

    Par exemple ici, renseigner comme son "nom" une magnifique alerte JS polluant le site voir même un beau lien froduleu et méchant '-' !

    Entrez votre nom : Mon non est <script>alert('MECHANT');</script>

    Faisant qu'en entrant son nom, le méchant très méchant (qu'on appellera "méchant") génère du code pour afficher son nom très méchamment !!
    Pouvant aller jusqu'à ajouter ses propres champs au site et diriger sur le siens, pirate et malveillant... Autant dire que ce n'est pas super.

    2°- Blade (et les gens biens) préconise(nt) donc d'utiliser le "specialchars" tel que :

    <?php $pseudo = htmlspecialchars($_POST['pseudo']); ?>

    Qui force les caractères spéciaux à apparaitre en DUR, en texte, et à ne pas passer comme code interpretable !

    Par exemple, avec "htmlspecialchars", notre méchant national verrait son plan échoué et son nom devenir :
    "Mon nom est <script>alert('MECHANT');</scrip>", purement et simplement :D
    (...Ou bien, cela convertirais les balises < et > en &lt; et &gt;, cassant le code)

    Et Blade charge lui tout seul les filtres "htmlspecialchars" aux champs voulu lorsqu'on les encadre de double accolades {{ !

    {!!, est en fait le moyen de contourner cette protection aux besoins !

    Donc j'imagine que certains préconisent les doubles accolades partout {{, par sécurité ..
    Et qu'il arrive qu'on recommande à l'inverse les exclamations pour encadrer de l'HTML {!!, de peur à ce qu'il ne soit pas interprété ...

    Je ne saurais te dire le fin mot de l'affaire si ce n'est de faire comme tu le sent,
    Préférant peut-être les doubles accolades {{au plus souvent et ce surtout sur les champs de saisies .. ?

    Toujours étant que la nature de ton problème venait (je pense) du mélange entre les deux écritures sur l'ouverture et la fermeture du formulaire.

    Garde donc à l'idée une notion d'harmonie dans ton choix de cadrage (partout pareil ou presque), et que les accolades offrent la sécurité XSS.
    Pour ma part j'ai testouillé 2 formulaires à la suite, écrits chacun sous l'une des façon de faire (l'un en {{ et l'autre en {!!partout),
    Et ils s'affichent de façon identiques... Alors c'est à creuser, mais dans l'idée {{est préférable sur des champs de saisies et {!! pour de l'HTML.

    J'espère ne pas t'avoir embrouillée aux restes, j'avoue que j'essaie de comprendre le fin mot de l'affaire en même temps alors je ne suis peut-être pas d'une grande aide ni clareté .. x)

  • Avatar de bestmomo
    Membre depuis :
    07/04/2013
    Messages :
    1461

    Salut,

    La double accolade est à utiliser en priorité parce qu'on a application de la fonction htmlspecialchars qui converti les balises HTML en code spécial et donc protège de l'insertion de code malveillant. Mais évidemment si on veut avoir effectivement les balises HTML il faut utiliser l'autre syntaxe avec les points d'exclamation.

    En résumé utiliser en priorité la syntaxe sécuritaire, surtout si on doit afficher des données qui ont été entrées par un utilisateur et réserver l'autre syntaxe pour la génération de code, par exemple pour un formulaire comme ici.

  • Avatar de L
    Membre depuis :
    21/07/2017
    Messages :
    20

    Merci beaucoup !! Je pense avoir bien compris la différence ! :)

Vous ne pouvez pas répondre à ce sujet.