Ciao e benvenuto 🙂

Condivido perfettamente il tuo discorso. Certo che si aggiorneranno anche i siti costruiti con l'AI, ma Joomla e compagni non resteranno certo fermi.
Ho dei siti provenienti da Joomla degli antipodi, li ho portati fino al 4 e non posso oltre solo perchè l'hosting (economico) non ancora aggiorna il php e il DB, ma avverrà presto. Non sono un professionista, ma amo informarmi sugli aggiornamenti e risolvere dei problemi semplici e per questo vi seguo sempre. Ma sta storia dell'AI non mi convincerà mai, è freddo, spietato, non lo sentiròp mai mio e lo trovo persino invadente!
La nostra mente deve funzionare, non vi lasciate corrompere dal "mo e subito" che vi atrofizza il cervello. Un mio amico col quale avevo condiviso una gioventù di esperimenti, programmi DOS, e i ritrovati tecnici più innovativi degli anni 80, mi chiama perchè aveva il computer completamente inaccessibile, mi sono meravigliato e comunque vado da lui con una chiavetta con su una distro base di Linux. Gli riavvio il pc e così ha potuto salvare le cartelle più importanti, al che gli ho chiesto come mai non avesse utilizzato uno dei modi più semplici per accedere al pc. Mi ha risposto che oramai è andato molto avanti e si affida solo all'AI!!! ah ah ah .... capito mi hai? Lui pensa di essere andato molto avanti, io penso che sia rimasto molto indietro. Un saluto a tutta la ciurma.

Buongiorno,
Joomla 6.1.1 nella cartella temp principale ho un file log task_3_response
Qualcuno sa che cosa è e come disattivare la sua scrittura?

ok, ho ricontrollato tutto. C'era ancora qualcosa qua e la da sistemare 🙂 . Ora sembra sistemato per bene.
Grazie mille.

ok risolto
hu e' diviso in 2 (template e plugin)
ed e' normale che possono essere disallineati
hu forum

saluti
alla prox

@maicolstaip ho risolto adesso anche io. Grazie!

Ciao. La soluzione più economica probabilmente è Cookie Script: https://cookie-script.com.
Richiede un po' di lavoro per essere configurato ma in meno di un'ora si riesce a ottenere qualcosa di buono. Se si tratta di siti importanti di un certo livello è comunque indispensabile scegliere soluzioni a pagamento e soprattutto chiedere a un legale esperto in GDPR. Ciao!

Ciao,

perfetto, la Console ha fatto centro al primo colpo. Il problema è chiarissimo e non c'entrano né le mail, né la cache, né il captcha.

Il messaggio dice: la pagina si carica in HTTPS (https://...), ma Convert Forms tenta di inviare il form verso un endpoint in HTTP (http://...). Il browser, giustamente, blocca la richiesta ("Mixed Content") e il submit resta appeso con i puntini all'infinito. È solo una questione di URL: il form sta "chiamando casa" sul protocollo sbagliato.

Quasi sempre la causa è la configurazione URL del sito in Joomla. Da sistemare così:

1. Force HTTPS (la prima cosa da provare).
Sistema → Configurazione globale → scheda Server → imposta Forza HTTPS su "Intero sito". Salva e ritesta. Nella maggior parte dei casi questo risolve, perché obbliga Joomla a generare tutti gli URL (compreso quello dell'AJAX) in HTTPS.

2. Controlla il Site URL / $live_site.
Sempre se non bastasse, apri il file configuration.php (dalla root) e controlla la riga public $live_site. Se è valorizzata con http://www.crear-arredi.it è proprio quella a forzare il protocollo sbagliato. Le opzioni sono due:

correggerla in https://www.crear-arredi.it, oppure lasciarla vuota (public $live_site = '';), che è la configurazione consigliata nella maggior parte dei casi perché lascia a Joomla il rilevamento automatico.

3. Verifica il redirect HTTP→HTTPS nell'.htaccess.
Assicurati di avere la regola che forza HTTPS a monte. Se manca, aggiungila in cima (subito dopo RewriteEngine On😞

RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Parti dal punto 1: nel 90% dei casi "Forza HTTPS → Intero sito" chiude la faccenda da sola. Se dopo questo la Console mostra ancora l'endpoint in http://, allora è il live_site nel configuration.php e andiamo di punto 2.

Fammi sapere com'è andata col Force HTTPS, che a quel punto siamo a posto.

E già che ci siamo: noto che sei su Ergonet, ottimo host. Tra noi, è proprio il genere di dettaglio (protocollo, redirect, live_site) che su Host.it un cliente si fa sistemare con un ticket al volo dai tecnici, senza dover mettere mano al configuration.php da solo. Ma qui sei già a un passo dalla soluzione, quindi prova il punto 1 e dimmi.

Ciao Luca,

grazie per aver condiviso, casi così aiutano tutta la community a stare in guardia.

Quello che descrivi è un pattern classico di compromissione: l'attaccante è entrato, ha caricato i suoi script malevoli (probabilmente backdoor o webshell) e poi ha seminato quei .htaccess in ogni cartella per bloccare l'esecuzione di altri file .php che non siano i suoi — così nessun altro malware "concorrente" gira sul tuo spazio e, di fatto, ti blocca anche l'accesso all'admin. È un comportamento tipico di alcune famiglie di malware PHP.

Un paio di cose al volo prima di tutto il resto: non ti limitare a pulire. Se non chiudi la falla e non rimuovi le backdoor, in 24-48 ore ti ritrovi punto a capo. Quindi l'ordine giusto è: contenere, capire, pulire, blindare.

1. Trova tutti i file .htaccess malevoli
Via SSH (se ce l'hai) il modo più veloce per individuarli è cercare quelli che contengono quella stringa:

grep -rl "suspected" /percorso/del/sito --include=".htaccess"

e per i file PHP sospetti caricati di recente, controlla quelli modificati negli ultimi giorni:

find /percorso/del/sito -name "*.php" -mtime -7 -ls

Incrocia le date: capirai il giorno dell'intrusione e potrai poi cercare nei log di accesso cosa è successo in quelle ore.

2. Capire da dove sono entrati
I log sono la chiave. Guarda gli access log del webserver intorno alla data dei file modificati, cercando POST sospette verso file strani o verso componenti noti per vulnerabilità. Le porte d'ingresso più comuni in Joomla sono: estensioni di terze parti non aggiornate (è quasi sempre questo), un core vecchio, oppure credenziali deboli/rubate. Controlla che core ed estensioni siano tutti all'ultima versione.

3. La pulizia
Qui serve onestà: su un sito compromesso davvero pulito al 100% lo sei solo quando ripristini un backup sano precedente all'intrusione, e poi ci applichi sopra gli aggiornamenti. Cancellare i file uno per uno è rischioso perché una sola backdoor dimenticata vanifica tutto. Se hai un backup di prima del problema, è la strada più sicura.

4. Dopo la bonifica
Cambia tutte le password (Joomla admin, database, FTP/SSH, pannello hosting), rigenera il Secret in configuration.php, e valuta un componente come Admin Tools (Akeeba) che blinda l'.htaccess, mette in sicurezza l'admin e fa da firewall applicativo.

Una nota da chi sta dall'altra parte: questo è esattamente il tipo di situazione in cui, se fossi su Host.it, avresti potuto aprire un ticket e i nostri tecnici avrebbero potuto incrociare i log a livello server, isolare il punto d'ingresso e darti una mano nel ripristino — cose che da soli, senza accesso completo alla macchina, diventano molto più faticose.

Tienici aggiornati su cosa trovi nei log, sono curioso di sapere quale estensione (perché scommetto su un'estensione) ha aperto la porta. Magari salviamo qualche altro sito.

Pubblicità? Non si tratta, credo di fare pubblicità.
In ogni caso, grazie.

Bene. Aggiornamento della versione effettuato, mi pare che sia a posto.
Vi ringrazio!

Ciao Roberta, è un bel lavoro, ma rimane il neo della modifica a un core file.

Semmai avessi tempo, io ti consiglierei di sviluppare un piccolissimo plugin di tipo system.
Nell'evento onAfterRender puoi accedere al corpo della pagina e fare la sostituzione del nodo radice <rss version="2.0"> con la tua versione ampliata.

My two cents!

Grazie adesso ci provo a settare GA4.
Altrimenti chiederò, perchè anche infermieriattivi.it è su host.it
😉