Frissítések kezelés webalkalmazásokban.
Sziasztok.
Kíváncsi vagyok rá, hogyan csinálják a "nagyok" a frissítés kezelést webalkalmazásokban! Pontosabban:
Van egy webalkalmazás (akár egy tartalom kezelő) ami feltelepítésre kerül jónéhány domain-re. Használat közben kiderül, hogy valamire van még szükség, vagy egy meglévő funkció nem felhasználó barát, akkor átíródik a kódrész. Ennek valahol elérhetőnek kellene lennie egy központi helyen, és a többi webalkalmazás időközönként ellenőrzi, hogy van-e frissítés, javítás a rendszerhez.
Így megoldható lenne, akár 100 különálló domainen futó alkalmazás automatikus frissítése és javítása egy helyről. De mégis hogyan?
Gondoltam arra, hogy a frissítéseket (a módosított fájlokat) betárolom mysql-ben és minden egyes domain-en engedélyezem annak az adatbázisnak az elérését. Így a frissítés valójában egy adatbázis művelet.
Mit gondoltok?
■ Kíváncsi vagyok rá, hogyan csinálják a "nagyok" a frissítés kezelést webalkalmazásokban! Pontosabban:
Van egy webalkalmazás (akár egy tartalom kezelő) ami feltelepítésre kerül jónéhány domain-re. Használat közben kiderül, hogy valamire van még szükség, vagy egy meglévő funkció nem felhasználó barát, akkor átíródik a kódrész. Ennek valahol elérhetőnek kellene lennie egy központi helyen, és a többi webalkalmazás időközönként ellenőrzi, hogy van-e frissítés, javítás a rendszerhez.
Így megoldható lenne, akár 100 különálló domainen futó alkalmazás automatikus frissítése és javítása egy helyről. De mégis hogyan?
Gondoltam arra, hogy a frissítéseket (a módosított fájlokat) betárolom mysql-ben és minden egyes domain-en engedélyezem annak az adatbázisnak az elérését. Így a frissítés valójában egy adatbázis művelet.
Mit gondoltok?
Capistrano
PEAR
Köszi!
biztonság
Nem teljesen értem, de...
Bejelentkezés után az alkalmazás észleli a frissítéseket és szól. Ha user a frissítést választja, akkor úgymond zárolja a rendszert és elkezdi kiolvasni az adatbázisból az új, vagy módosított fájlokat változóba. Ha kiolvasta, kiírja a meghatározott könyvtárba.
Nem akarok fájl részleteket cserélni, csak egész fájlokat.
Biztonság
Ez némi lelki nyugalmat ad abból a szempontból, hogy ha egy támadó saját kódot képes futtatni a szevreren (pl remote include vagy hibás fájlfeltöltő rutin), akkor sem képes a kódunkat megváltoztatni (és mondjuk egy backdoort elhelyezni későbbi használatra).
Az alap unix biztonsági dörgedelem is úgy tartja: minden felhasználónak csak annyi jogot szabad adni, ami feltétlenül szükséges. Ha az update funkcionalitás miatt a PHP processzeket felruházod a módosítás jogával, akkor gyengítesz a biztonságon. Kérdés, hogy megéri-e.
Érthető.
Ez valóban alkalmazás függő, körültekintően kell eljárni a felhasználók hatáskörének megszabásával.
Az én terveim szerint a felhasználó mást nem tud tenni, mint képet (ami keresztül megy egy gd átméretezésen) és pdf fájlt feltölteni, szöveges tartalmat bevini, néhány html tag kivételével szigorúan strip_tags. Usernek nincs képessége ezeket a fájlokat a szerveren manipulálni (nem tud átnevezni include-olni stb.).
Egyébként nem teljesen értem!
Ha van egy View, egy Modell vagy egy Controller, ami megváltozik és ennek a megváltozott változatát betárolom adatbázisba, ahonnan a frisstés kezelő kiolvassa, az azonos nevűt átnevezi (hogy lehessen helyreállítani) majd létrehozza újra az új tartalommal, ebben hol lehet biztonsági rés?
Pardon?
Kíváncsi vagyok mit hozol ki
Mi van ha frissítés közben megszűnik az internet, elérhetetlen a központi szerver? Mi van ha más Mysql verziót használ és fellép valami inkompatibilitás?
Esetleg szétnézhetsz olyasmiben, hogy automatizálsz egy SVN folyamatot.
A folyamat lépései.
- Bejelentkezés gyanánt user megadja az adatait hitelesítésre. Ha a hitelesítés rendben van, akkor a szokásos átirányítás helyett visszakap user egy dialógust, hogy vannak elérhető frissítések. Ha nem kér a frissítésből, akkor megy minden tovább a standard eljárás szerint (kérheti, hogy egy hétig ne legyen figyelmeztetés újra), ha kér,
- átirányítódik a frissítés kezellőbe. Itt jóváhagyhatja a frissítéseket és a frissít gombra kattint.
- Ekkor létrehozok egy helyreállítási pontot, ami szintén egy adattábla. Ebben a táblában regisztrálom a frissítés kezdetét, és befejezését. Értelem szerűen, ha a frissítés elkezdődik, akkor a vonatkozó dátummező értéket kap, majd ha befejeződik akkor a befejezést igazoló dátummező is értéket kap.
- Megszerzem a központi adatbázisból az új fájl adatait és tartalmat, a régit bemásolom a helyreállítási pont kezelő adatáblába (valószínüleg egy másik tábla, ami a módostott fájlokat tartalmazza és távoló kulcsa a helyreállítási pont id-je) létrehozom az újat, majd összehasonlítom a lemezre írt fájlt és a távoli adatbázisból hozott fájl tartalmat. Ha minden stimmel, akkor ez ehhez a fájlhoz trtozó frissítve dátummező értéket kap.
- Ez addíg megy, míg minden fájl elkészül, és ha minden rendben van, akkor a helyreállítási pont befejezve dátummezője is értéket kap.
Ha megszakad az internet, vagy bármi gebasz keletkezik, akkor a következő bejelentkezésnél (értelem szerűen minden bejelentkezésnél) ellenőrzöm, hogy van-e lezáratlan helyreállítási pont. Ha van, elküldöm usert a helyreállításhoz és készítek egy diagnosztikát, mit sikerült frissíteni és mit nem...
Mas megkozelites
Azonos kódra épülnek.
Valaki felreert valamit
Tényleg félreértettem!