Author: Martin

Jeder der mit Laravel und einer Datenbank arbeitet kommt zwangsläufig auf das Thema Mass Assignment. Was ist das eigentlich?

Beziehungsweise ihr kennt diese HTTP 500 Fehlermeldung:
Add [name] to fillable property to allow mass assignment on [App\Models\Profil].

Stellen wir uns vor wir haben eine Website mit einem geschütztem Dashboard für unsere Nutzer. Ein registrierter Nutzer kann unter anderem sein Profil bearbeiten. Beispielsweise: Email, Vorname, Nachname, Strasse usw. Stellen wir uns weiter vor, dass wir in unserer Applikation dem Nutzer verschiedene Rollen zuweisen können. Zum Beispiel Premiumnutzer, Admin oder ähnliches.

Wenn der Nutzer über ein Formular sein Profil bearbeitet und an das Backend abschickt passiert dann folgender Ablauf. Im Backend Controller wird der Request entgegengenommen. Zum Beispiel:

public function update_profil(Request $request) {
	$id = $request->input('id');
	$name = $request->input('name');
	$street = $request->input('street');
	$email = $request->input('email');	

	// oder einfach mit:  
	$alleDaten = $request->all(); 

	// Dann werden die Daten zum Model weitergeben. 
	$profil = Profil::find($id);
	$profil->name = $alleDaten['name'];
	$profil->street = $alleDaten['street'];
	$profil->email = $alleDaten['email'];
	$profil->save();  
}

Das wars! Dieser Weg ist gut aber bei mehreren Feldern auch mühselig. Weil man noch Validierungen, Plausibilitäten usw. vornehmen muss. Eine einfache Alternative wäre das ganze Request Array ( $request->all() ) am Stück dem Model Profil zu übergeben. Man nennt das auch Mass Update. Quasi so :

Profil::where('id', 1)->update( $request->all() );
// oder: 
$profil = Profil::find($id);
$profil->update( $request->all() ); 

Was kann aber nun ein Bösewicht hier böses machen? Genau er kann versuchen den – nennen wir die Datenbankspalte mal – user_type in das Formular mit dem value „admin“ einschleusen. Nicht gut, wenn wir nun über ein unvalidiertes Mass Assignment die Daten updaten. Kommt öfters vor als man denkt. Deshalb ist es wichtig das Konzept der fillable und guarded Spalten im Model zu verstehen und auch überlegt anzuwenden.

Genau aus diesem Grund gibt es im Model auch die protected Klassenvariablen $fillable und $guarded .

fillable()

...
protected $fillable = ['name', 'password', 'email']; 
...

Hier trägst Du ein welche Felder so geupdatet werden dürfen. Felder die nicht im fillable Array stehen werden auch nicht berücksichtigt.

guarded()

Die Model Klassenvariable $guarded ist genau das gegenteil von fillable. Hier schreibst du die Spaltennamen rein, die nicht geupdated werden dürfen. Also in unserem Fall user_type.

Man kann auch sagen, fillable ist eine whitelist und guarded eine blacklist. Beides braucht man nicht. Entscheidet einfach selbst welchen Ansatz ihr verfolgt.

Wichtig ist zu wissen, sobald man mit Mass assignment oder mass update arbeitet die fillable bzw. guarded zu setzen.

Möchte man das alle Felder erlaubt sind, dann muss man nicht extra alle Felder in fillable einfüge sondern kann einfach:

protected $guarded = []

und ohne viel Schreiberei das lösen.

Wer sein Code Testgetrieben schreibt und bei Laravel seine Testdatenbank auf SQLITE geschaltet hat, wird eventuell auf ein SQLITE Problem treffen, wenn man in seiner Migration Datei ein Enum Feld hat. Da kann zum Beispiel solch eine Fehlermeldung kommen:

Tests\Feature\CustomerTest > created customer and found by email 
Illuminate\Database\QueryException 

  SQLSTATE[HY000]: General error: 1 no such table: customers (SQL: insert into "customers" ("organisation_or_person", "gender", "first_name", "last_name", "email", "phone", "place", "street", "street_number", "zip_code", "country", "updated_at", "created_at") values (organisation, male, John, Steiner, martin@martin.com, 0272516913, Wegberg, Behrensallee, 6, 12989, de, 2020-11-07 14:43:45, 2020-11-07 14:43:45))

Hier ein kleiner Hinweis wie man seine Testdatenbank auf Sqlite einstellt. Geht dazu in die phpunit.xml Datei und tragt folgende zwei Zeilen in den php Block ein. In den jüngsten Laravel Versionen sind die Felder bereits vorhanden und es muss nur noch die Auskommentierung gelöscht werden.

<server name=”DB_CONNECTION” value=”sqlite”/>
<server name=”DB_DATABASE” value=”:memory:”/>

Dann sieht das ganze wie folgt aus:
<php>
<server name=”APP_ENV” value=”testing”/>
<server name=”BCRYPT_ROUNDS” value=”4″/>
<server name=”CACHE_DRIVER” value=”array”/>
<server name=”DB_CONNECTION” value=”sqlite”/><!—->
<server name=”DB_DATABASE” value=”:memory:”/><!—->
<server name=”MAIL_MAILER” value=”array”/>
<server name=”QUEUE_CONNECTION” value=”sync”/>
<server name=”SESSION_DRIVER” value=”array”/>
<server name=”TELESCOPE_ENABLED” value=”false”/>
</php>

Zurück zum eigentlich Problem. Das Problem ist auch sehr simpel. SQLITE kennt keine ENUM Felder. Es kennt auch keine JSON Felder so wie MySQL. Deshalb ändern wir für unsere Testdurchläufe den Type von enum zu string. Packen das aber vorher in eine Bedingung. Und zwar, soll das nur passieren, wenn wir einen Test fahren. Geht zu euren Migration Dateien wo die ENUM Felder drin sind und baut die Condition if (config(‘app.env‘ === ‘testing‘) {} ein.

Die If Condition sieht dann in eurer Migration Datei so aus.

    public function up()
    {
        if (config('app.env') === 'testing' ) {            
            Schema::create('customers', function (Blueprint $table) {                
                $table->id();
                $table->string("organisation_or_person");
                $table->string("gender");
                $table->string("first_name");
	    // ...
            });            
        } else {            
            Schema::create('customers', function (Blueprint $table) {
                $table->id();
                $table->enum("organisation_or_person", ["organisation", "person"]);
                $table->enum("gender", ["male","female"]);
                $table->string("first_name");
	    // ...
	}
}

Für den einen oder anderen mag das vielleicht nicht ausreichen. Es gibt auch einen weiteren Weg, wie man ENUM Felder in SQLITE zum laufen bringt. externer Link

Stellt euch dieses Beispiel ma vor. Wir haben in unserem SPA Frontend ein Formular. Es soll mit Hilfe eines Formulars eine XHR Anfrage mit Geodaten Lat und Lng gesendet werden. Der Server führt dann ein HTTP Reuqest auf die Google Places Api durch und schickt uns das Resultat als Json zum Frontend zurück. Im Frontend haben wir also zwei Inputfelder (id=“lat“ und id=“lng“) und ein Sende Button. Beim klicken des Buttons feuern wir eine Ajax Anfrage an unseren Server (GET /api/call_google_places_by_lat_lng). Der Api Router leitet die Anfrage an den entsprechenden Controller und die dafür bestimmte Methode weiter.

<input id="lat" value=""> 
<input id="lng" value=""> 
<button id="btn-action">And Action!</button>

In unserer Routes Verzeichnis passen wir nun die API Route in der api.php an.

Route::get('call_google_places_by_lat_lng/', [App\Http\Controllers\GooglePlacesController::class, 'call_google_places_by_lat_lng']);

Mit dem Konsolen Programm Artisan erstellen wir einen neuen Request.

php artisan make:request RequestGeoDataForGooglePlacesCall

In der neuen Request Klasse passen wir bei Bedarf die authorize() Methode an. Falls Ihr ohne Authorisierung arbeitet, müsst ihr hier den boolischen Rückgabewert auf true setzen. Das bedeutet dann, man muss nicht Authorisiert sein um diesen Request abzusetzen. In Rules schreibt ihr Eure Formcalidations Regel nieder. Für die Validationsregeln lege ich Euch die Laravel Validation Dokumentation nahe. Die Möglichen Errornachrichten könnt Ihr auch noch nach belieben anpassen. Das macht ihr in der Methode messages(). Hier mal meine Beispiel Custom Request Klasse.

class RequestGeoDataForGooglePlacesCall extends FormRequest
{
    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'placeid' => ['required','max:10'],
        ];
    }

    /**
     * Get the error messages for the defined validation rules.
     *
     * @return array
     */
    public function messages()
    {
        return [
            'placeid.required' => 'The Google Places ID field is required.',            
        ];
    }    
}

Nun zurück nun zum Controller. Hier müsst ihr die neue Request Klasse dem Controller bekannt machen.

use \App\Http\Requests\RequestGeoDataForGooglePlacesCall;

und dann der Funktion dem Typ des $request mitgeben. Jetzt könnt Ihr mit der Requestmethode validated() Eure Requestvariable checken lassen.

public function test_new(SendGeoDataForGooglePlacesCall $request) 
{
    $request→validated();
    // ...
}

Hier mal ein Postman Request zum Überprüfen. Achtet bei Postman Request auf den HTTP Header. Setzt unter Headers Key auf Accept und den dazugehörigen Value auf application/json . Ansonsten leitet Euch Laravel bei nicht erfolgreicher Validierung mit einem 302 auf eure Anfrageseite zurück. Wenn der Header richtig gesetzt wurde, solltet ihr ein HTTP Statuscode 422 und folgende Fehlermeldung als Json erhalten.

Jetzt könnt ihr das nach belieben erweitern und verfeinern. Man muss nicht zwingend mit einer eigenen Request Klasse arbeiten. Ihr könnt genauso gut auch die Validierung im Controller vornehmen.