Un fastidioso errore 404 mi risultava dalla visita di uno dei miei siti (che utilizzano come http server nginx su sistema operativo CentOS), e mi sembrava che l’attribuzione dei permessi fosse corretta.

L’errore HTTP 404 viene emesso dal server web quando non trova nel file system la risorsa (file o cartella) corrispondente all’URI che gli viene passato dal client (ad esempio Google Chrome o Firefox): il famoso errore di Pagina non trovata.

Questo errore si verifica anche se il file c’è ma si verifica una di queste condizioni:

• l’utente sotto il quale sta girando il server non ha permessi di lettura sul file desiderato né come utente né come gruppo
• non ha la possibilità di raggiungere quella risorsa percorrendo il grafo della directory da / al file desiderato

In realtà basta infatti che una directory della catena di “cd command” (change directory) che il servizio web deve fare non sia leggibile e si verifica l’errore. Il modo più efficiente di vedere lo stato di tutta la gerarchia di directory è utilizzare il comando namei:

namei - follow a pathname until a terminal point is found

[root@websrv01 site]# namei -om /usr/share/nginx/html/
f: /usr/share/nginx/html/
 dr-xr-xr-x root     root       /
 drwxr-xr-x root     root       usr
 drwxr-xr-x root     root       share
 drwxr-xr-x root     root       nginx
 drw-rwSr-- www-data developers html

Qui è evidente il problema: tutta la catena di directory ha l’opzione x (eXecute) tranne la directory contenente la DocRoot del web server (la directory html) ragion per cui è sufficiente aggiungere questo permesso:

[root@websrv01 site]# chmod a+x /usr/share/nginx/html/
[root@websrv01 site]# namei -om /usr/share/nginx/html/
f: /usr/share/nginx/html/
 dr-xr-xr-x root      root       /
 drwxr-xr-x root      root       usr
 drwxr-xr-x root      root       share
 drwxr-xr-x root      root       nginx
 drwxrwsr-x www-data  developers html
[root@websrv01 site]# 

Il problema è risolto.

Un commento a latere dell’utilizzo del web server

Dare a root la directory pubblica del web server non è una buona prassi.

Dare indistintamente permessi di esecuzione al web server in una directory di root non è a maggior ragione una buona prassi.

Le cartelle sotto il dominio del web server vanno assegnate ad un utente specifico e a questo va dato il permesso di x.

Devo testare delle API con Unit Test di una classe Category. Come primo passaggio genero la classe di Test:

php artisan make:test CategoryTest

Questo comando mi genera un file sotto tests/Feature/CategoryTest.php che tosto personalizzo come segue, un metodo per ogni operazione del CRUD:

<?php

namespace Tests\Feature;

use App\Category;
use Tests\TestCase;
use Illuminate\Foundation\Testing\WithFaker;
use Illuminate\Foundation\Testing\RefreshDatabase;

class CategoryTest extends TestCase
{

    public function testsCategoriesAreCreatedCorrectly()
    {
        $headers = ['Authorization' => "ajs8ebddau"];

        $payload = [
            'name' => 'Libri e Riviste INS',
            'short' => 'libri INS',
        ];

        $this->json('POST', '/api/categories', $payload, $headers)
            ->assertStatus(302)
            ->assertJson([
                'name' => 'Libri e Riviste INS',
                'short' => 'libri INS'
            ]);
    }

    public function testsCategoriesAreUpdatedCorrectly()
    {
        $headers = ['Authorization' => "ajs8ebddau"];

        $category = new Category;
        $category->name = 'Libri e Riviste TEST';
        $category->short = 'libri TEST';
        $category->save();

        $id = $category->id;

        $payload = [
            'name' => 'Libri e Riviste UPDATE',
            'short' => 'libri UPDATE',
        ];

        $response = $this->json('PUT', '/api/categories/' . $id, $payload, $headers)
            ->assertStatus(200)
            ->assertJson([
                'id' => $id,
                'name' => 'Libri e Riviste UPDATE',
                'short' => 'libri UPDATE'
            ]);
    }

    public function testsCategoriesAreDeletedCorrectly()
    {

        $headers = ['Authorization' => "ajs8ebddau"];

        $id = 30;

        $payload = [
            'name' => 'Lorem',
            'short' => 'Ipsum',
        ];

        $category = new Category;
        $category->name = 'Libri e Riviste DEL';
        $category->short = 'libri DEL';
        $category->save();
        $id = $category->id;

        $response = $this->json('DELETE', '/api/categories/' . $id, $payload, $headers)
            ->assertStatus(200);
    }

    public function testCategoriesAreListedCorrectly()
    {
        $category = new Category;
        $category->name = 'Libri e Riviste first';
        $category->short = 'libri first';
        $category->save();

        $category = new Category;
        $category->name = 'Libri e Riviste second';
        $category->short = 'libri second';
        $category->save();

        $headers = ['Authorization' => "ajs8ebddau"];

        $response = $this->json('GET', '/api/categories', [], $headers)
            ->assertStatus(200)
            ->assertJson([
                [ 'name' => 'Libri e Riviste first', 'short' => 'libri first' ],
                [ 'name' => 'Libri e Riviste second', 'short' => 'libri second' ]
            ])
            ->assertJsonStructure([
                '*' => ['id', 'name', 'short', 'created_at', 'updated_at'],
            ]);
    }
}

In realtà la variabile $headers qui è superflua, ma mi viene comoda dopo, quando aggiungerò lo strato di autenticazione.

Eseguo i test

marcob@jsbach:shopping3$ composer test
> vendor/bin/phpunit
PHPUnit 7.4.0 by Sebastian Bergmann and contributors.

.....                                                               5 / 5 (100%)

Time: 248 ms, Memory: 16.00MB

OK (5 tests, 7 assertions)
marcob@jsbach:shopping3$ 

Il comando di test qui è dato utilizzando composer, in quanto ho definito uno script “test” all’interno del file di configurazione composer.json: alla sezione script ho aggiunto:

    "scripts": {
        ...
        "test" : [
            "vendor/bin/phpunit"
        ]
    },

L’alternativa è scrivere semplicemente vendor/bin/phpunit

Boost your web application

HTML è un linguaggio di mark-up in cui sono stati definiti molti tag per conferire una semantica al testo. Quindi ci sono i marcatori di titolo h1, …, h6 per definire la gerarchia delle titolazioni nelle sezioni del documento, come i tag per le liste, i paragrafi, le immagini e così via.

Ogni marcatore (tag) è corredato di una serie di attributi standard che vengono utilizzati sia da browser che dai programmi Javascript per interagire con il DOM (Document Object Model).

Nulla vieta però all’occorrenza di definire degli attributi personalizzati (custom) se l’applicazione ne ha bisogno. Il browser ignorerà tali attributi per quanto riguarda la visualizzazione ma li metterà comunque a disposizione nel DOM per poter essere utilizzati dai programmi Javascript. Come esempio di un caso d’uso possiamo aver bisogno di identificare l’icona di un utente del social network che stiamo sviluppando etichettandolo con l’id univoco che rappresenta l’utente nello spazio dati:

<img src="images/placeholder-small.jpg" userid="8zn4938d9z3" ...>

userid non è un attributo standard; nella visualizzazione il browser non lo prederà in considerazione, però potremo accedervi con Javascript:

<script>
console.log(img.getAttribute('userid'));
</script>

Potrebbe esserci un problema di conflitto di nomi, se abbiamo definito un nome attributo che viene utilizzato in modo diverso da più librerie Javascript entrambe agenti sulla stessa pagina HTML.

HTML5 [1] da’ la possibilità di definire una convenzione per cui se i nomi degli attributi personalizzati iniziano con data-

<img src="images/placeholder-small.jpg" data-userid="8zn4938d9z3" ...>

allora i valori sono reperibili direttamente con un accesso all’oggetto img.dataset

console.log(img.dataset.userid);

Oppure con AngularJS è possibile la stessa cosa utilizzando il prefisso ng-* (le cosiddette direttive con le quali AngularJS estende gli attributi HTML):

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.7.8/angular.min.js"></script>
<img ng-userid="8zn4938d9z3">

Un esempio più illuminante è il seguente in AngularJS nel quale definisco una direttiva completamente custom:

<div ng-app="coolApp" pippo-directive>

<script>

var app = angular.module("coolApp", []); 
  app.directive("pippoDirective", function() {     
     return {         
         template : "Testo definito nel callback del costruttore della direttiva!"     
     }; 
  }); 
</script>

Il tag coolApp (che definisce l’app AngularJS) ha una direttiva completamente custom pippo-directive che viene agganciata da Javascript tramite la directive app.directive, il cui nome è la versione camel-case del nome dell’attibuto HTML.

Fonti

[1] https://www.w3.org/TR/2011/WD-html5-20110525/elements.html#embedding-custom-non-visible-data-with-the-data-attributes

[2] https://code-maven.com/custom-html-attributes