A teljes rendszer frissítése, vagy egyes modulok frissítése nem kerülhető ki az update.php használata nélkül. Ugyanakkor átnevezni sem előnyös, mert időnként hibákat okoz.
Tehát az autentikációval nem rendelkező nem éppen jó szándékú emberek, vagy robotok próbálkozhatnak a fájl elérésével. Még azon rövid idő alatt is, ha csak a frissítések idejére kerül fel a szerverre a fájl.
Ekkor a fájl a következőt írja ki:
In order to run update.php you need to either be logged in as admin or have set $settings['update_free_access'] in your settings.php.
Szerintem ez nem előnyös. Szeretnék vagy egyedi üzenetet tenni a kiírás helyére, vagy egyszerűen a főoldalra irányítani az admin hozzáféréssel nem rendelkező próbálkozókat.
Van erre megoldás drupal8 alatt?
Sajnos egyelőre nem találtam a problémára megoldást.
Haat..
Szerintem ebből csak te csinálsz problémát, eddig még senkinek sem volt belőle baja, és szerintem nem is lehet megcsinálni core hack nélkül. Az update.php egy speciáls UpdateKernel classt használ, ami be van drótozva. Szóval vagy írsz egy saját Kernelt, és átírod az update.php-t, hogy azt használja, vagy az UpdateKernelt írod át.
Egyik sem javallott.
Esetleg egy KernelEvents::REQUEST eventre meg lehet próbálni ráakaszkodni subscriberrel, de nem vagyok benne biztos, hogy ez az update.php-nél lefut. Baar.. Ez már nagyon Symphony, de lehet, kipróbálom.
De ha még sikerül is. Mivel itt nincs még nincs betöltött user, saját magadnak kell sessiont ellenőrizni, kvázi összerakni a usert, hogy le tudd ellenőrizni, hogy admin-e.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Biztonság
Mostanában sokat foglalkoztam a drupal biztonságával. Például, hogy miként futtatható a webes főkönyvtáron kívülről. Ez kis pluszmunkával elérhető és csupán néhány, vagy néhány tíz megabyte plusz tárhely veszteséggel jár a telepített moduloktól függően.
Ennek tesztelése közben figyeltem fel, hogy az update.php kijelentkezett módban mit dob vissza. A legjobb az lenne, ha beállítható lenne, hogy ezt a fájlt milyen ip-ről jövő kérés esetén lehet futtatni. Most eszembe is jutott valami...
Természetesen ezt a fájlt a frissítés után el lehet távolítani, de a közben beérkező kérések esetén sem kellene plusz információt kiadni, ha muszáj, akkor inkább logba lehetne menteni, de a legjobb az lenne, ha nem írna ki semmit, vagy a főoldalra dobná a felhasználót.
Szerintem éles rendszeren hasznosabb lenne így.
'Például, hogy miként
'Például, hogy miként futtatható a webes főkönyvtáron kívülről. Ez kis pluszmunkával elérhető és csupán néhány, vagy néhány tíz megabyte plusz tárhely veszteséggel jár a telepített moduloktól függően.'
Milyen plusz munkát meg néhány 10 megát? Nálam kb mindig így volt 0 plusz munkával meg plusz tárhellyel.
'A legjobb az lenne, ha beállítható lenne, hogy ezt a fájlt milyen ip-ről jövő kérés esetén lehet futtatni.' - .htaccess a barátod, valami ilyesmivel:
'Szerintem éles rendszeren hasznosabb lenne így.' - semmi értelme sincs, lényegtelen, nincs semmilyen biztonsági, vagy egyéb kockázata. A kutyát nem érdekli az az update.php, nem ezt fogják nyaggatni, ha kínozni akarnak. Ebből csak te csinálsz problémát.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
js,css... fájlok miatt van plusz tárhely.
Sajnos egyes modulok esetén szükség van arra, hogy a js, css, svg és egyéb front-end fájlok elérhetőek legyenek a php és a web számára is.
Amikor a szerver mögött van a core, akkor a php eléri, de a webes kérések nem érik el ezeket a fájlokat. Így szinkronizálni kell őket. (Hiába a css és js aggregáció mégis előfordulnak időnként külön hivatkozott fájlok.)
Ha jobb megoldásod van én szívesen venném, ha megosztanád, amit előre is köszönök!
Én ezt a megoldást használom:
Moving all PHP files out of the docroot
Ahh sorry, ezt a részt
Ahh sorry, ezt a részt félreértettem, teljesen másra gondoltam.
Amúgy én ezt nem érzem criticalnak, pláne mondjuk egy drupal-composer/drupal-project template-tel, ami a vendor dirt eleve kívülre teszi.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Igen én is ismerem azt a verziót...
Én is megismertem anno azt a verziót, de aztán elkezdtem gondolkodni rajta, hogy miért ne tehetném a vendor helyett az egész drupal-t hátra.
A composer nagyszerű dolog, de nem mindig használható. A legjobb, ha a szerveren is futtatható, de ez nem mindenhol lehetséges.
Játszottam, már feles megoldást is. Helyzetfüggő, mikor mire van szükség, vagy mit lehet, illetve mi az egyszerűbb.
Szóval végül a linkelt megoldásnál maradtam. Szerintem ez a legjobb. Persze nyugodtan meg lehet cáfolni, -nem sértődöm meg -mindig szívesen tanulok új dolgokat :)!
Próbálkoztam az assets és misc mappa kihelyezésével a core-ból, de nem működött jól így maradt a fenti megoldás a teljes szinkronizálással.
Itt is korán írtam a kérdést, mert közben rájöttem, hogy miért is kéne a drupal update.php fájlját bántanom, mikor úgy is egy átirányító fájlon át érem el. Abban pedig, már meg is csináltam az ip szűrést. Amikor szükség van rá felteszem a megfelelő ip-vel a frissítés után, meg leveszem. Így a .htaccess fájlt sem kell bántanom.
Minden esetre nagyon köszönöm a segítséget!