Deploy su Aruba senza SSH: i workaround che uso ogni giorno

Lo stack reale: cosa hai e cosa non hai su Aruba shared

Aruba hosting condiviso Linux ti dà: PHP 8.x, MySQL/MariaDB, FTP, pannello cPanel, .htaccess, cURL abilitato. Non ti dà: SSH, terminale, Composer, Node.js, npm, accesso a crontab, exec()/shell_exec().

Per molti developer questo è un dealbreaker. Per me è un vincolo creativo che ha reso il mio codice più pulito, più leggero e più resiliente. Ecco i workaround che uso quotidianamente su 5+ siti in produzione.

Workaround #1: PHPMailer senza Composer

PHPMailer è la libreria più usata per inviare email in PHP. L'installazione "standard" è composer require phpmailer/phpmailer. Su Aruba non puoi.

La soluzione: scarica il repository da GitHub, carica via FTP solo la cartella src/ dentro una directory vendor/PHPMailer/, e includi manualmente i 3 file necessari.

# Struttura su Aruba (via FTP)
/vendor/
  /PHPMailer/
    /src/
      PHPMailer.php
      SMTP.php
      Exception.php

// Include manuale — nessun autoloader necessario
require_once __DIR__ . '/vendor/PHPMailer/src/PHPMailer.php';
require_once __DIR__ . '/vendor/PHPMailer/src/SMTP.php';
require_once __DIR__ . '/vendor/PHPMailer/src/Exception.php';

use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

// SMTP Aruba: SEMPRE ssl sulla porta 465
$mail = new PHPMailer(true);
$mail->isSMTP();
$mail->Host       = 'smtps.aruba.it';
$mail->SMTPAuth   = true;
$mail->Username   = 'info@tuodominio.it'; // casella creata nel pannello Aruba
$mail->Password   = 'password-casella';
$mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS; // SSL, non TLS
$mail->Port       = 465; // non 587

Workaround #2: reCAPTCHA v3 con cURL

Google reCAPTCHA v3 richiede una verifica server-side: invii il token a Google e ricevi la risposta. La maggior parte delle guide usa file_get_contents() con un URL remoto. Su Aruba, allow_url_fopen è spesso disabilitato per motivi di sicurezza.

// PRIMA (non funziona su Aruba): file_get_contents
$response = file_get_contents(
    'https://www.google.com/recaptcha/api/siteverify?secret=' . $secret . '&response=' . $token
);

// DOPO (funziona ovunque): cURL
function verifyRecaptcha($token, $secret) {
    $ch = curl_init();
    curl_setopt_array($ch, [
        CURLOPT_URL => 'https://www.google.com/recaptcha/api/siteverify',
        CURLOPT_POST => true,
        CURLOPT_POSTFIELDS => http_build_query([
            'secret'   => $secret,
            'response' => $token,
        ]),
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_TIMEOUT => 10,
    ]);
    $response = curl_exec($ch);
    curl_close($ch);
    
    $data = json_decode($response, true);
    return ($data['success'] ?? false) && ($data['score'] ?? 0) >= 0.5;
}

Regola generale su Aruba: ogni volta che una guida suggerisce file_get_contents() per URL remoti, sostituisci con cURL. Funziona sempre.

Workaround #3: Debug senza terminale

Senza SSH non puoi fare tail -f error.log. Il mio sistema di debug su Aruba:

// 1. Logger custom su file (leggibile via FTP o browser protetto)
function debugLog($message, $context = []) {
    $logFile = __DIR__ . '/logs/debug_' . date('Y-m-d') . '.log';
    $entry = date('H:i:s') . ' | ' . $message;
    if ($context) $entry .= ' | ' . json_encode($context, JSON_UNESCAPED_UNICODE);
    file_put_contents($logFile, $entry . "\n", FILE_APPEND);
}

// 2. Pagina debug protetta (solo da IP noto o con token)
// ver.php — ritorna PHP info e stato dei servizi
if ($_GET['key'] !== 'mia-chiave-segreta') { http_response_code(403); exit; }
echo 'PHP: ' . phpversion() . "\n";
echo 'cURL: ' . (function_exists('curl_init') ? 'OK' : 'NO') . "\n";
echo 'Mail: ' . (function_exists('mail') ? 'OK' : 'NO') . "\n";

Workaround #4: Pseudo-cron per task periodici

Senza crontab, i task periodici (pulizia sessioni, sync iCal, invio email programmate) si eseguono come "pseudo-cron" piggyback sulle visite degli utenti.

// Pseudo-cron: esegui task periodico al primo visitatore dopo X secondi
function pseudoCron($taskName, $intervalSeconds, $callback) {
    $lockFile = sys_get_temp_dir() . '/cron_' . $taskName . '.lock';
    
    if (file_exists($lockFile) && (time() - filemtime($lockFile)) < $intervalSeconds) {
        return false; // troppo presto
    }
    
    touch($lockFile);
    
    // Esegui in "background" (non blocca la pagina per l'utente)
    if (function_exists('fastcgi_finish_request')) {
        fastcgi_finish_request(); // invia la risposta al browser, poi esegui
    }
    
    $callback();
    return true;
}

// Utilizzo: pulizia sessioni ogni 6 ore
pseudoCron('session_cleanup', 21600, function() {
    // elimina sessioni più vecchie di 24 ore
});

Workaround #5: Protezione file sensibili

Su Aruba i file PHP nella document root sono accessibili via URL. File come db.php (credenziali database) devono essere protetti con .htaccess:

# .htaccess nella root del sito

# Blocca accesso diretto a file sensibili

    Order Allow,Deny
    Deny from all


# Blocca directory listing
Options -Indexes

# Blocca accesso alla cartella logs

    RewriteRule ^logs/ - [F,L]

Il workflow quotidiano

Il mio ciclo di sviluppo su Aruba: sviluppo in locale (XAMPP), testo su un ambiente staging (sottocartella /dev/ sul server), e deploy via FTP con FileZilla. I file modificati li traccio mentalmente o con un semplice diff locale. Non è glamour, ma funziona su 5+ siti in produzione con uptime del 99.9%.