wake-up-neo.net

Ist die reguläre Ajax-Anforderungsmethode sicher oder sollte ich admin-ajax.php verwenden?

Auf der Homepage habe ich einige Links:

<a class="link" data-id="1">first link</a>
<a class="link" data-id="2">second link</a>
<a class="link" data-id="3">third link</a>

Wenn auf einen dieser Links geklickt wird, möchte ich eine Ajax-Anfrage an eine PHP-Datei senden, um die Datenbank zu aktualisieren und die Ansichtsspalte dieses Beitrags zu vergrößern.

$(document).ready(function(){
    $(document).on('click', '.link', function(e){

        var post_id = $(this).data('id');

        $.ajax({ 
            url: "views.php",
            type: 'POST',
            data: {id: post_id},
            success: function(){
                alert("done");
        }}); // ajax

    }); // on click

}); // ready

In views.php:

//Check if the id is posted.
if( isset($_POST['id']) ){

    //Assigning the id to a variable.
    $id = $_POST['id'];

    //Check if the id is an integer.
    $pattern = '/[0-9]/';
    if( preg_match($pattern, $id) ){

        //Check that the user didn't visit that post before.
        $post_cookie = 'p_' . $id;
        if( !isset($_COOKIE[$post_cookie]) ){

            //Insert or update if the post id exists.
            $query = $conn->prepare('INSERT INTO posts (id, views) VALUES (:id, 1) ON DUPLICATE KEY UPDATE views = views+1');
            $query->bindValue(':id', $id, PDO::PARAM_INT);
            $query->execute();

            //Set a cookie with the post id to indicate that the post is viewed.
            setcookie( $post_cookie, '1');

        }// No cookie with that name (the user didn't visit that post).
    } // id matches the pattern.
} // id is posted.

Ich könnte andere Optionen als die Beitrags-ID verwenden, um die Ansichten hinzuzufügen/zu aktualisieren. Ich frage mich jedoch, ob dieser Weg sicher ist oder ich die Datei admin-ajax.php verwenden sollte.

Die Beiträge sind benutzerdefinierte Beiträge aus der Datenbank, keine WordPress-Beiträge

2
Dan

OMG ... Nein, nein, nein !!! Mach das niemals so ...

Warum? Es gibt viele Gründe...

  1. Sie können mit Benutzern in Ihrem views.php nichts anfangen - was ist, wenn Sie nur die Aufrufe von anonymen (nicht angemeldeten) Benutzern zählen müssen?

  2. Was ist, wenn table_prefix auf '' gesetzt ist? Ihre posts Tabelle verursacht Konflikte ...

  3. Was ist, wenn es Plugins gibt, die mit einer DB-Verbindung arbeiten? Ihr Skript stellt eine Verbindung zur falschen Datenbank her oder verursacht andere Konflikte.

  4. Was ist, wenn Ihr Skript aus Sicherheitsgründen nicht ausführbar ist?

  5. Es gibt noch viele andere Gründe, warum Sie es nicht so machen sollten ...

Es gibt einen Grund für Best Practices und Standards. Und das Leben aller Entwickler ist viel einfacher und angenehmer, wenn alle nach diesen Standards und Praktiken programmieren ... Auf diese Weise ist es einfach, alle AJAX Aufrufe zu debuggen und so weiter ...

Also ja, Sie sollten auf jeden Fall admin-ajax.php und wp_localize_script und $wpdb und eine korrekte SQL-Escape-Anweisung verwenden und so weiter ...

Was ist der Unterschied? Ist die Ajax-Funktion für die Benutzer nicht sichtbar?

Ja, es wird sichtbar sein. Aber ... Es wird kein Standard-AJAX -Aufruf sein - daher wird es schwieriger zu verstehen sein ...

Machen wir ein kurzes Experiment ... Sehen wir uns diese beiden Codes an:

1.

add_action( 'wp_ajax_get_post_status', 'ajax_get_post_status_callback' );
function ajax_get_post_status_callback() {
    $id = $_POST['id'];
    $post = get_post( $id );

    if ( $post ) {
        echo $post->post_status;
        die;
    }

    echo 0;
    die;
}

2.

include "ustawienia-polaczenia.php";
$i = $_POST['id'];
$wiersz = PostsQuery()::create()->filterById( array($i) )->find();
if ( $wiersz ) {
    echo $wiersz->post_status;
    die;
}

echo 0;
die;

Welches ist leichter zu lesen? Ich wette der erste. Warum? Weil es WP Kernfunktionen verwendet und jeder weiß, wie sie funktionieren. Ich weiß (oder ich kann leicht überprüfen), was die get_post Funktion tut und so weiter. Dieser Code respektiert auch alle Filter und Aktionen - so werden keine Konflikte mit anderen Plugins erzeugt ...

Andererseits ist der zweite Code nur ein Durcheinander ... Er enthält eine andere Datei, verwendet eine seltsame DB-Verbindung (ja, es ist Propel). Es ist sogar schwer zu erraten, ob es sich um dieselbe oder eine andere Datenbank handelt und wie genau dies funktioniert. Und es ignoriert vollständig alle anderen Plugins ...

Also ja - jeder wird sehen, dass Ihr Code seltsame AJAX sendet und welche Datei für die Verarbeitung verantwortlich ist. Das Problem ist, dass das Debuggen Ihres seltsamen/benutzerdefinierten Codes viel mehr Zeit in Anspruch nimmt ... Und es ist viel wahrscheinlicher, dass Ihr Code Probleme und Konflikte verursacht ...

3