Üdv!
Olyan statikus HTTP hoszting szolgáltatót keresek, ahol be lehet állítani olyat, hogy ha a kért resource nem létezik, akkor automatikusan elinduljon kifelé a fában, és behozza az első index.html - t, amit talát.
Tehát pl. e helyett:
https://www.example.com/proba/szoveg/valami/random
kiszolgálja szépen, hogy
https://www.example.com/proba/index.html
... ha a kért resource amúgy 404, és a próba könyvtáron belül lett volna
Alternatívaként az is jó, ha bizonyos PATH-okra fixen be lehet állítani, hogy ne is keresgéljen belül, hanem minden, ami adott pattern alá esik, az mennyen az index.html - re.
Mindez arra kell, hogy az adott oldalon futó single-page web app megkapja szépen a requesteket, a kért path többi részét már az app fogja feldolgozni, JS-ből, kliens oldalon.
* * *
Gondolom apache / nginx alatt valami URL rewrite-tal meg lehet csinálni ezt nem túl nehezen, a kérdés, hogy melyik szolgáltató enged ilyet?
Egyéb követelmények:
- Menjen a saját domain és az SSL
- A tartalmat lehessen valami CLI tool segítségével inkrementálisan frissíteni. (Pl. git, rsync, vagy bármi, amit az rclone ismer.)
Ebben szeretnék tanácsot kérni.
Köszönettel.
- 448 megtekintés
Hozzászólások
VPS? Azt csinálsz rajta amit akarsz (nagyjából)...
- A hozzászóláshoz be kell jelentkezni
De nem akarom kézzel konfigurálni, amit nem kell... meg kézzel frissítgetni, patchelgetni a web szervert, a modulokat, stb... szolgáltatást keresek.
- A hozzászóláshoz be kell jelentkezni
Ezt a robotok, crawler és rosszindulatúak miatt egyaránt nem akarod. Ha rewrite-tal össze lehet hozni és támogatott, akkor menni fog. Az CLI tool-os frissítés FTP vagy SFTP vonalon lesz inkább támogatott.
- A hozzászóláshoz be kell jelentkezni
Kérlek részletezd, hogy mi itt a gond a robotokkal, a crawlerekkel és a rosszindulatúakkal.
- A hozzászóláshoz be kell jelentkezni
Nincs igazi 404-es oldalad, mindenre lesz találat, phpmyadminra, webmailekre, mindenre, amivel próbálkoznak és ha sikerül "jól beindulniuk", akkor igen könnyen bedönthetik a VPS-ed vagy hostingot. Ha nem döntik be, akkor benne van a pakliban, hogy olyan forgalmat csinálnak, hogy eléred az adatforgalmad végét. A crawlerek egy rész még referer alapján tiltható, meg néhány sűrű próbálkozás, de mindíg jön valami új és mégcsodálatosabb.
A csúcsok csúcsa az, amikor a Google indexel olyan agresszíven, hogy ledönti a több VPS-ből álló kiszolgáló hadat, igaz ott a PHP kód az hogyismondjam, nem volt optimális.
- A hozzászóláshoz be kell jelentkezni
Nem adnék mindenre találatot, csak az adott path-on belüli oldalakra.
Tehát http://example.com/phpmyadmin az 404,
viszont http://example.com/app/item1 viszont menne az app/index.html -ből kiszolgált single page app-ra.
(/app2/item2 meg ay app2/index.html / re.)
Nem hiszem, hogy ezt agyon másznák a pókok.. vagy igen?
- A hozzászóláshoz be kell jelentkezni
És az example.com/foo/phpmyadmin? és az example.com/nincsilyen/ilyensincs/phpmyadmin az meg yool a /index.html-re, ha jól gondolom...
- A hozzászóláshoz be kell jelentkezni
a /nincsilyen-es izék mennének 404-ra simán.
De amúgy meg ez legyen a hosting site problémája, gondolom kezelik valahogy. phpmyadmin-t soha az életben nem kell kiszolgálniuk, ha egyszer statikus html az egész szolgáltatás...
- A hozzászóláshoz be kell jelentkezni
rewriteolsz minden urlt, a fo /index.php-ra, majd abban szepen lekezeled hogy keresse meg amit kell, es azt adja vissza.
nginx/apacheba is meg lehet talan oldani, de azzal csak szopas lesz, es nem is biztos hogy 100%-osan mukodik.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Közben úgy nézem, hogy a surge.sh nagyjából tudja, amit kerestem. Kipróbálom este..
- A hozzászóláshoz be kell jelentkezni
Itt ez van: https://surge.sh/help/adding-a-200-page-for-client-side-routing
Ez nagyjából jó is, csak annyi kellene még, hogy ezt könyvtár szinten lehessen állítani, ne csak globálisan az egész site-ra nézve...
- A hozzászóláshoz be kell jelentkezni
Nem egészen értem. Ha az appjaid az example.com/app1, example.com/app2 stb. címeken vannak, akkor miért nem minden az alatti nem létező URL-t a „gyökérre” rewrite-olsz? Minek ehhez egyesével felmászni a könyvtárstruktúrán odáig?
- A hozzászóláshoz be kell jelentkezni
Rewrite-olhatok úgy is, az teljesen jó, ha van ilyen config lehetőségem.
Abból indultam ki, hogy .htaccess írási jogot nem annyira akarnak adni a hoszting szolgáltatók, security okok miatt, és ezért olyan konfig lehetőségeken gondolkodom, amit esetleg adhatnának is.
De ha van editálható htaccess, modul betöltési joggal és működő htaccess-sel, az teljesen jó.
- A hozzászóláshoz be kell jelentkezni
Abból indultam ki, hogy .htaccess írási jogot nem annyira akarnak adni a hoszting szolgáltatók
Ilyet még nem láttam.
De ha van editálható htaccess, modul betöltési joggal
Ilyet sem. Minek töltögetnél modulokat? Milyen modul kéne, ami egy átlag hostingon nincs?
- A hozzászóláshoz be kell jelentkezni
GitHub pages: nincs htaccess jogosultság
BitBucket pages: nincs htaccess jogosultság
S3 buckets for public access: nincs htaccess jogosultság
Szóval azért van bőven, hogy nincs.
- A hozzászóláshoz be kell jelentkezni
Szerintem nagyon más fogalmaink vannak a webhostingról.
Amiről te beszélsz, azok cloud storage static web megoldások. Ott nem fog menni, amit szeretnél.
- A hozzászóláshoz be kell jelentkezni
Ez tök egyszerű. index.html preferáltabb legyen, mint az index.php, majd az index.php semmi mas mint ugrik egyszinttel feljebb. Emellé kell egy htaccess ami mindent az index.php-ra irányít, ami nem létező fájl.
- A hozzászóláshoz be kell jelentkezni
Közben látom, hogy a netlify biztosan tudja, amit kerestem...
- A hozzászóláshoz be kell jelentkezni
Felmásztam a hup tárhelyszolgáltatójához és ráböktem az első csomagra. Az elég is lesz neked.
- A hozzászóláshoz be kell jelentkezni