Apropo de ce spunea misterr, am găsit pozele mele de la Club !!!!
viewtopic.php?f=236&p=269937#p269937
viewtopic.php?f=80&t=276&start=280#p269916
Cum de au ajuns acolo la alți useri ?

ATENȚIE !!!
Aproximativ la ora afișată iar mi-a dat o eroare pe adresa forumului :

Mie imi miroase suspecta treaba asta cu site-uri care apar aiurea din cand in cand. Nu cred ca e OK sa se intample asta. Nu vreau sa par paranoic, dar pare-mi-se ca suntem (indirect prin host) tinta unui atac.

Sfatuiesc pe cei care au ajuns pe site-urile dubioase sa isi schimbe parola.

Iar mi-a dat eroare pentru câteva minute

Stai asa, abwebhosting.com? Hostul nu era hostmama.ro?

......

Hostul este, intr-adevar, hostmama.ro. Mie asta nu mi se pare neaparat un atac, ci erori punctuale in rezolvarea numelui metrouusor, intern, la ei. O sa dau mai departe...

Apariția unor pagini de pe alte site-uri, respectiv alte directoare în structura din sistemul de fișiere al server-ului companiei de hosting nu reprezintă un atac sau un sabotaj, ci o consecință a modului în care funcționează conceptul de „Shared hosting”, eventual și cu o mică eroare sau desincronizare de natură umană. Mai multe site-uri de la mai mulți beneficiari stau pe același server fizic, sub același sistem de operare, cu request-uri susținute de aceași aplicație de web server. Astfel, ca serverul să „știe” ce site să trimită pentru domeniul cerut de browser, se folosesc niște fișiere de configurare numite „Virtual Host”, acestea făcând legătura între domeniu, fișiere efective pe disc și configurarea specifică aplicației ce rulează în director. În momentul în care din DNS (partea de legătură domeniu - IP) sau din routare la nivel de rețea se trimite un domeniu către o adresă sau o mașină care nu a fost configurată să îl servească, software-ul de webserver va răspunde inițial cu directorul implicit, nu cu cel configurat pentru site. Astfel se explică eventualele site-uri de pe alte domenii care au apărut temporar (cât au mutat ei configurația printre serverele cu cPanel, până a preluat daemon-ul acel fișier) și eventualele erori din tranziție - (also, pentru a verifica alte site-uri pe IP-ul curent se poate folosi site-ul https://www.yougetsignal.com/tools/web- ... eb-server/, a găsit un andanelectron.ro care share-uiește același IP cu forum.metrouusor.com). Deci nu este o problemă pentru securitatea conturilor/parolelor pentru cei care au ajuns pe site-uri aiurea. E un rateu din configurația pre-migrare/pre-reconfigurare efectuată desincronizat.

Ce este însă inexplicabil este seria de erori referitoare la SSL: ba expiră, ba e servit pentru alt domeniu... dacă Let's Encrypt e configurat corect pe serverul gazdă, ar trebui să fie automat și solid... Și evident cum a crăpat așa din senin DB-ul.

Pentru a rezolva aceste „overlap-uri”, cel mai indicat e să te ocupi de propria ogradă și să stai pe un VPS / cloud cu propriul sistem de operare și propriul sistem de server, unde îți administrezi propriul mediu de deployment, site, DB, backup-uri, IP, etc. Evident, este puțin mai scump (nu cu mult, în zilele noastre, a se vedea DigitalOcean de exemplu) în special pentru a egala sau depăși performanțele unui server shared puternic și necesită mai multă implicare din partea echipei tehnice de administrare proprii a site-ului, dar pentru un domeniu cu mult trafic e cel mai bine să te ocupi cu propriile resurse și cunoștințe. Anyway, asta e la latitudinea administrației și să sperăm ca astfel de probleme să fie cât mai rare.

De la a gresi site-ul din cauza unor configuratii pana la a spune ca nu exista risc de securitate este un mare pas, mai ales daca certificatele SSL nu sunt in regula. Daca incerci sa faci login si requestul se duce pe un alt site si cu certificat SSL dubios, atunci poti fi sigur ca parola ta a fost compromisa, si astfel de riscuri nu trebuie trecute cu vederea.

Nu va impacientati. A fost o eroare majora si au trebuit sa ne mute pe alt server fizic, atata doar ca au facut-o pe bucati (baza partial, fisierele cam toate, certificatele ssl deloc). Cum toate site-urile noastre redirecteaza catre https automat, a aparut eroarea pe care ati vazut-o (requestul cerea explicit un certificat care nu exista).

Legat de alternative - nu este cazul. Chiar daca nu sunt perfecti, oamenii astia remediaza problema atunci cand le spui, ceea ce e ideal in conditiile in care noi avem joburi si obligatii care nu ne lasa sa fim 100% disponibili, deci "mai multa implicare" este tehnic imposibil din partea noastra.

misterr wrote:
Încă nu a apucat să indexeze mesajele aduse la loc (pe forumuri apare: „Ultimul mesaj: 03.04.2018”, dar în forumuri sînt și mesajele din 04.04.2018).

Costin wrote:
Am resetat contoarele si cred ca e ok acum.

Deocamdată e tot așa.

Din ce se vede, lucrurile funcționează în felul următor:

Atunci cînd se adaugă un mesaj pe forum prin interfața web, se întîmplă două lucruri:
1. Se scrie mesajul într-o tabelă din baza de date (cu data și ora lui)
2. Se aplică un „timestamp” într-un cîmp din altă tabelă, în care este ținută evidența datei și orei ultimului mesaj din fiecare subforum/topic.

Atunci cînd se adaugă / se șterg manual mesaje din baza de date (cum s-a făcut acum cu mesajele din 4 aprilie), se execută doar punctul 1, iar acel timestamp din cealaltă tabelă nu se mai modifică.
Practic, în paginile cu titlurile topicelor sînt afișate timestamp-urile aplicate atunci cînd au fost adăugate ultima dată mesaje prin interfața web, nu mai este interogată din nou baza de date pentru a vedea data/ora ultimului mesaj (se presupune că nu le-a mai modificat nimeni manual între timp). Într-adevăr, e mai rapid așa (sînt mai puține interogări și e „frecată” mai puțin baza de date), dar pot apărea erori ca cele pe care le vedem acum.
De aceea apare că data ultimului mesaj din topice este 28 martie, 2 aprilie etc..., deși sînt topice în care au fost adăugate mesajele din 4 aprilie.

Soluția ar fi de făcut un script care să se uite în fiecare topic să vadă care e data/ora ultimului mesaj și să rescrie acele timestamp-uri. Se pot modifica și manual, pentru că nu sînt multe topice în situația asta (cu mesaje din 4 aprilie), or fi vreo 10.

Misterr a intuit corect si problema, si solutia. Acum toate topicele ar trebui sa arate corect data/ora ultimului mesaj.

Altă belea:
- s-a modificat doar data și ora, și doar în subtopice (în topicele „părinte” a rămas la fel) - probabil structura e mai complexă, se creează cîte un timestamp pentru fiecare topic (părinte) / subtopic (copil)
- numele userilor au rămas tot cele dinainte (deci nu mai e corelat numele userului cu data și ora ultimului mesaj) - probabil și numele userilor care au scris ultimul mesaj sînt în altă tabelă

Exemple (cu navigare pagina principală -> topic -> subtopic):

1.
- prima pagină (https://forum.metrouusor.com/index.php)
- topicul „Știri, noutăți și discuții despre metrou” (https://forum.metrouusor.com/viewforum.php?f=21)
- data / ora ultimului mesaj: Mie Apr 04, 2018 12:07 am
- ultimul user: ZOLI

- pagina „Știri, noutăți și discuții despre metrou” (https://forum.metrouusor.com/viewforum.php?f=21)
- topicul „Titluri de călătorie și sisteme de acces” (https://forum.metrouusor.com/viewtopic.php?f=21&t=1691)
- data / ora ultimului mesaj: Mie Apr 04, 2018 9:45 pm
- ultimul user: ZOLI

- pagina „Titluri de călătorie și sisteme de acces” (https://forum.metrouusor.com/viewtopic.php?f=21&t=1691&start=1288)
- data / ora ultimului mesaj: Mie Apr 04, 2018 9:45 pm
- ultimul user: misterr

2.
- pagina „Comunitatea MetrouUsor” (https://forum.metrouusor.com/viewforum.php?f=104)
- topicul „Clubul "Flacara Rosiatica" (https://forum.metrouusor.com/viewtopic.php?f=104&t=1109)
- data / ora ultimului mesaj: Mie Apr 04, 2018 8:14 pm
- ultimul user: mcosmin

- pagina „Clubul "Flacara Rosiatica" (https://forum.metrouusor.com/viewtopic.php?f=104&t=1109&start=2982)
- data / ora ultimului mesaj: Mie Apr 04, 2018 8:14 pm
- ultimul user: misterr

Ok. Mai sap...