Martin: Proč? Nic se od roku 2021 nezměnilo (jen je na Alíkovi o kousek víc lidí).

Takhle jsem to nemyslel, chtěl jsem říct, že si myslím, že už tady není moc lidí, co by to využilo...

Chtěl bych tu jen pro pořádek zmínit, že už máme přibližně týden funkční OAuth. Jde tedy vyrábět externí služby, které budou mít přihlašování Alíkem (pokud jim to dovolíme, nemáme to úplně otevřené).

Martin: Doména Koalík.cz je pořád namířená někam k tobě, ne? Takže závěr „už to není aktuální, protože kutilové se nesnaží!“ mi přijde divný.

Už jsem tu dřív psal, že u Tuxe je riziko, že uteče, což se tak nějak potvrdilo. (Momentálně je i zablokovaný, protože vyhodnotil, že jsme mu dobří jen k tomu, aby odtud odváděl lidi do spárů Facebooku. )

Pokud je potřeba nějaká podpora z mé strany, tedy pokud je potřeba něco naprogramovat uvnitř Alíka nebo rozhodnout, tak jsem k službám komukoliv, kdo se toho chopí.

To je asi ten problém. Chcete hned všechno na 100%, místo toho aby jste začali aspoň s něčím . Pak se to nikdy nikam nehne.

Ale přijde mi, že aktivita programátorských kutilů se dost snížila, takže podle mě už Alíkův webhosting není aktuální téma, nebo věc, do které by se vyplatilo jakkoliv investovat.

Martin: ISPConfig použít nemůžeme, a to například z toho důvodu, že standardně podporuje pouze skriptovací jazyky typu Perl, PHP, Python a Ruby. My budeme časem chtít podporu i pro jiné jazyky, jako například Go a Node.js. Navíc také obsahuje spousty věcí, které podle mého názoru ani moc potřebovat nebudeme.. Já bych byl spíše pro, pokud možno, čisté, elegantní, jednoduché a modulární řešení :)

YOYO:

Já jsem se docela dlouho rozmýšlel, jestli webovou službu prozatím napíšu v jazyce PHP a jako webový server zvolím Apache/Lighttpd/Nginx, anebo ji raději rovnou napíšu v jazyce Go a jako webový server zvolím Caddy. Nakonec jsem se rozhodl pro tu druhou variantu :)

„Idčka entit nemusí být přímo v adresách, jak naznačují ukázky, ale mohou být spolu s ostatními parametry umístěné v těle požadavku, nejspíš jako JSON data.“

Já bych spíše souhlasil s tím, aby se veškeré požadované identifikátory předávali přímo v těle HTTP požadavku, jako data zapsaná ve formátu JSON :)

„Autorizační klíč/token může být také v těle požadavku, a nebo v HTTP hlavičce.“

Autorizaci by asi spíše bylo lepší předávat přímo v hlavičce HTTP požadavku, ale to už pak asi spíše záleží na tom, jak se navzájem domluvíme :)

Martin,
myslím, že jsi nenapsal API pro pro komunikaci mezi Alíkem a webhostingem, ale spíš mezi jednou částí tvého systému a druhou částí, která Ti ještě chybí.

Alík si nebude ukládat žádné databaseId, ftpId a jiné údaje - to bude vše na straně Koalíka.

Nechci hanit tvou práci, možná je to něco, na čem by šlo stavět, ale takhle jak to máš to není použitelné.

Možná byste s Tuxem mohli nějak spojit síly?

Pojďme se ale zamyslet, jaké konkrétní hodnoty bude potřeba posílat v daných požadavcích:

Myslím, že Alík si (asi) nebude chtít ukládat žádné nové informace, které ještě nemá - ani identifikátory webů (navíc je lepší mít jen jeden „zdroj pravdy“). Takže navrhuji přidat ještě sedmý endpoint, který by vracel seznam webů daného uživatele. (Aby si SA mohli vylistovat weby uživatele a nějaký z nich mu zablokovat - jestli chápu dobře, že něco takového má být možné pro SA z jejich Alíkovské administrace)

Tento endpoint může být přístupný veřejně všem, i bez autorizace.
/api/user/{userId}/webs - vrátí seznam webů daného uživatele
Případně můžeme přidat i
/api/users - vrátí seznam všech uživatelů
nebo
/api/webs - vrátí seznam všech webů
to už je drobnost.

Z těch šesti akcí, některé ovlivňují web, některé samotného uživatele.
Otázka je, zda v případě, že má jeden uživatel více webů, bude chtít Alík volat akci pro smazání/zablokování každého webu zvlášť, a nebo zda to má mít jednu společnou akci, která to provede hromadně.

To druhé mi asi dává větší smysl, u těch akcí, kde by se to stejně vždy provádělo pro všechny weby uživatele (je nesmysl blokovanému uživateli znepřístupnit jen jeden jeho web), takže bych to upravil takto:

/api/web/create - vytvoří nový web (a uživatele pokud ještě neexistuje)
/api/web/{webId}/delete - smaže konkrétní web (to asi nebude potřeba)
/api/web/{webId}/off - vypne konkrétní web
/api/web/{webId}/on - zapne konkrétní web

/api/user/{userId}/disable - znemožní přistup uživatele ke všem jeho webům
/api/user/{userId}/enable - umožní přístup uživateli ke všem jeho webům
/api/user/{userId}/delete - smaže uživatele a všechny jeho weby

• akce s `user` budou mít jako parametr id uživatele, třeba 398504
• akce s `web` budou mít jako parametr id webu (asi název subdomény, vymyšlený uživatelem při nákupu v katalogu)
• /api/web/create, bude navíc požadovat i id uživatele a jeho přezdívku (pro vytvoření účtu na straně Koalika)

Idčka entit nemusí být přímo v adresách, jak naznačují ukázky, ale mohou být spolu s ostatními parametry umístěné v těle požadavku, nejspíš jako JSON data.

Autorizační klíč/token může být také v těle požadavku, a nebo v HTTP hlavičce Authorization: Bearer <token>.

(poznámka pro Martina: ten apiKey (a obecně jakékoliv tajné hodnoty) bys neměl ukládat přímo ve zdrojáku, ale měl bys ho načítat z nějaké své env proměnné. V php pomocí getenv.)

MM
Otázka:
Jak řešit přejmenovávání účtu?

Na straně Koalíka budeme potřebovat znát a mít uloženou přezdívku uživatele. Minimálně pro vylistování v nějakých těch seznamech.

V ostatních případech - při používání ve vlastní relaci přihlášeného uživatele - by to šlo asi načítat přímo z OAuth/session dat.

Myslím, že většinu tohoto by usnadnil ISPConfig, ostatně jsem již API pro komunikaci mezi Alíkem a tím serverem (ISPConfigem) základně napsal...

Samozřejmě by se tam pak některé ty věci dopsaly (například pouze vypnutí webu nebo vypnutí FTP uživatele pro správu webu.

Přijde mi to jako logické řešení, než psát znova všechny skripty pro vytvoření databáze, FTP uživatele, domény, SSL certifikátu, podpory různých programovacích jazyků...

API na GitHubu

Dokumentace API na GitHubu

Navíc si pak lze přímo v ISPC prohlížet všechny weby, databáze, jejich velikosti, a pokud by se něco pokazilo, přece jen je možnost ty weby přehledně spravovat přímo na serveru, bez nutnosti programovat něco, co už existuje.

YOYO: Souhlasím.

„Ale pro MMa bude asi jednodušší používat na vše jen GET nebo jen POST, podle toho jak se domluvíte“
Bude. Není nutné vymýšlet nějaké luxusní rozhraní, nebude to používat nikdo kromě nás. Stačí mi cokoliv, co se jednoduše používá a co je dostatečně neprůstřelně bezpečné.

„Povolit přístup ke zdrojovým souborům ostatním uživatelům“
Chtěl bych toto mít nějak víc vynucené. Neděláme obecný webhosting, jakých už existují desítky. Kdo nechce, aby zdrojový kód byl vidět, může jít jinam.

Tux: „Ale jaký je prosím přesně rozdíl mezi vypnutím a zapnutím webu a zakázáním a povolením jeho správy? Nešlo by to celé dát pouze do dvou operací místo čtyř? Jakože při vypnutí webu by se zároveň zakázala i jeho správa? :)“
Jedno je vypnutí webu a jedno je zákaz úprav… v tom není vidět rozdíl?

• Pokud někdo zlobí na Alíkovi a vyslouží si za to třeba týdenní blokaci celého Alíka, tak nedává žádný smysl potrestat uživatele jeho webu tím, že jim ten web vypneme.
• A naopak pokud někdo vyrobí něco nevhodného na svém webu (třeba díru, kvůli které mu tam začne vznikat nelegální obsah) a správce Alíka mu ten web vypne, tak nedává žádný smysl zablokovat mu správu toho webu.

Tux:

Dovolím si odpovědět, MM mě klidně může doplnit/opravit.

Těch 6 akcí o kterých je řeč, to by mělo být implementováno jako webová služba (web service) - a tedy používat http(s) rozhraní.

To znamená, že budeš mít například 6 různých endpointů (URL adres), který každý bude něco provádět, například:

https://koalik.cz/api/web/create
https://koalik.cz/api/web/delete
https://koalik.cz/api/web/on
https://koalik.cz/api/web/off
https://koalik.cz/api/web/enable
https://koalik.cz/api/web/disable

Požadované hodnoty, jako identifikátor webu/uživatele a nějaký autorizační token dokazující, že ten požadavek posílá fakt Alík, by se předávaly jako payload v JSON formátu. A odpovědí budou taky nějaká JSON data (například pro vrácení chybové hlášky, kdyby se něco nepovedlo).

(Případně by jich mohlo být méně a použít různé http metody - POST pro vytvoření, DELETE pro zrušení - po vzoru REST. Ale pro MMa bude asi jednodušší používat na vše jen GET nebo jen POST, podle toho jak se domluvíte)

Udělej to třeba v tom jazyce Go, nebo v PHP,... teoreticky můžeš nakonfigurovat Apache (nebo nginx, caddy...), aby pro každý ten požadavek volal rovnou nějaký tvůj shell script (CGI) - ale to nezní moc dobře. Rozumnější bude použít nějaký pokročilejší jazyk, bude to robustnější, bezpečnější. Lépe se ti bude dělat validace hodnot, atd.
Nějaké shell příkazy můžeš pak volat rovnou z toho Go, pokud to bude potřeba, například pro vytvoření systémového uživatele - ale spoustu úkonů můžeš dělat pomocí systémových volání přímo v tom tvém programu (jako vytvoření adresáře a tak).

Kromě tohoto rozhraní, které bude volané výhradně z Alíka, by to pak chtělo ještě nějaké webové rozhraní pro samotné uživatele.

Takový uživatel by mohl chtít třeba:
V soukromé části:

• Znepřístupnit svůj web pro veřejnost - například pokud na něm zrovna pracuje.
• Povolit přístup ke zdrojovým souborům ostatním uživatelům
• Nahrát/upravit svůj veřejný SSH klíč aby mohl přistupovat ke svým souborům přes sftp
• Nahrávat soubory přes webové rozhraní, pokud nechce používat sftp
• Editovat soubory přímo v tom webovém rozhraní, pokud je nechce (nebo nemůže 📱) editovat na počítači
• Nastavit si používání vlastní domény, místo koaličí subdomény

Ve veřejné části:

• procházet si seznam webů ostatních uživatelů
• procházet si zdrojové soubory webů uživatelů kteří to mají povolené

Na toto webové rozhraní se bude přihlašovat skrze Alíka, za použití toho OAuth, na kterém jistě už MM pilně pracuje.

A může to být implementované buď jako oddělá věc od toho rozhraní pro Alíka, a nebo to může být dohromady. Oba přístupy mají výhody i nevýhody.

–MM–:

Pro vzájemnou komunikaci a zasílání požadavků z webového rozhraní na virtuální privátní server bych navrhoval zabezpečený shell (neboli také SSH protokol), anebo jsou nějaké jiné nápady? :)

V každém případě to ale musí být něco, co se dokáže bezpečně přihlásit na vzdálený server pod konkrétním uživatelským účtem, který bude mít nastavená oprávnění pro spouštění mocných skriptů shellu :)

První dvě jsou jasné. Klasické operace „create“ a „delete“. Ale jaký je prosím přesně rozdíl mezi vypnutím a zapnutím webu a zakázáním a povolením jeho správy? Nešlo by to celé dát pouze do dvou operací místo čtyř? Jakože při vypnutí webu by se zároveň zakázala i jeho správa? :)

Navíc upřímně nevím, co přesně je myšleno právě tou správou.. Jediná věc, která bude sloužit pro správu webu, bude akorát nástroj na správu databází (jako je například phpMyAdmin). Jinak mě už nic jiného nenapadá.. :)

Rozhodně souhlasím s vytvořením jakéhosi testovacího serveru, na kterém byste si předem mohli vyzkoušet plnou funkcionalitu, a ze kterého by se to pak později dalo celé snadno přenést na skutečný virtuální privátní server :)

Vybavení pro to tady na to v každém případě mám, pak už jde jenom o to, zpřístupnit vám to i v rámci veřejného internetu, a ne jenom v rámci mé lokální sítě, což už bych však ale také nějak zařídil.. :)

Tux: To, že ajťáci nedotahují projekty do konce, je celkem normální.

Teď už platíme od roku 2021 za doménu, kterou v podstatě nepoužíváme. To je pár stovek ročně investovaných do předpokladu, že něco někdy vznikne. Nechceme se dostat do stavu, kdy bychom dlouhodobě platili i pár stovek měsíčně za něco, co zatím nefunguje. Sice by nás to nezruinovalo, ale snažím se uvažovat alespoň trochu ekonomicky.

Krom toho by o kousek víc hrozilo, že by sis začal sám sobě vyčítat, že to nestíháš tak rychle, jak bys chtěl, a že nás tím finančně poškozuješ. Působíš na mě jako citlivý člověk a nechci ti způsobovat tento druh stresu. Raději bych dal ty peníze třeba přímo tobě než za rok pronájmu nevyužívaného virtuálního serveru.

Pokud něco vyrobíš, bude to připravené k nějakému nasazení a testovacímu spuštění, tak fajn, rozběhneme to, ale zatím mi to přijde pořád takové… teoretické.

„ale někdo to musí připravit i na straně Alíka“
Zkusíme pohnout s tím OAuthem.

Myslím, že z Alíka bude chodit jen omezená sada pokynů:

• zřiď web (při schválení žádosti koupené přes katalog dárků),
• znič web (při zapomenutí účtu),
• vypni web (při vypnutí účtu nebo zásahem správce),
• zapni web (při opětovném zapnutí účtu nebo zásahem správce),
• zakaž správu webu (při zablokování účtu na Alíkovi),
• povol správu webu (při odblokování účtu na Alíkovi).

–MM–:

A jak přesně by podle tebe měl vypadat ten náznak? :)

Ano, uvědomuji si, že po jedné mé zkušenosti už prostě nejsem schopný nic dotáhnout do konce, ale nemyslím si, že zrovna v tomto případě by tomu tak bylo :) Opravdu bych si přál, aby Alík měl svůj vlastní webhosting :)

Dobře, já to můžu připravit na straně webhostingového serveru, ale někdo to musí připravit i na straně Alíka, a ten někdo zároveň musí komunikovat i se mnou, aby se nám to pak celé podařilo vzájemně propojit :)

Tux: Než začnu pravidelně platit za další zapnutý VPS, tak bych chtěl vidět nějaký jasnější náznak, že to povede k žádanému cíli.

Věřím ti, že s tímto projektem skutečně chceš pomoct, vážím si této snahy, ale zároveň si na základě zkušeností uvědomuji riziko (a nyní se prosím neuraz), že se může kdykoliv stát, že zase od všeho utečeš.

Víceméně přesný popis toho, co je chtěno, jde seskládat z příspěvků v této nástěnce. Pokud je něco nejasného, ptej se a bude ti odpovězeno.

Jo diky

Rychlošípka: Hodně zjednodušeně řečeno se v podstatě jedná o jakýsi pronajatý prostor na vzdáleném serveru, sloužící pro nahrávání tvých vlastních webových stránek, které jsou pak díky tomu snadno dostupné i z veřejného internetu :)

Co je to webhosting?

–MM–:

To, s tím písmenkem, byl jen a pouze můj návrh. Je na vás, jak si to tady na Alíkovi uděláte :)

Za mě osobně by tedy byla daleko lepší autorizace na základě certifikátů a klíčů, ale pokud za každou cenu chcete otevřený autorizační protokol (neboli také „OAuth2.0“), máte ho mít :)

Potřeboval bych od vás celkem dvě věci. A to za prvé přesný popis toho, jak to má pak ve výsledku celé vypadat, a za druhé přihlašovací údaje k virtuálnímu privátnímu serveru :)

Tux: Žádost o vytvoření se bude kupovat v katalogu, nemyslím si, že by se kvůli jedné stránce mělo obsazovat další písmenko a zakládat speciální sekce tady.

Samotná administrace hostovaného webu by měla probíhat jen na koalik.cz.

„Pokud bychom se chtěli zcela vyhnout klasickému ověřování na základě hesel“
Použijeme standardní OAuth. Konečně bude důvod ho zavést.

„Jen bych k tomu potřeboval dostat oprávnění.“
Co to přesně znamená?

Vždyť nějak takhle je to už domluvené, ne?

Nedávno jsem si čirou náhodou vzpomněl na tuto nástěnku a shodou okolností mě zároveň napadl i nový způsob, jak celý tento projekt implementovat. A to bez jakéhokoliv API třetích stran, či dalších podobných věcí.

Tento projekt bych nadále rozdělil na dvě části, z nichž první by měli na starosti vývojáři Alíka a tu druhou bych měl na starosti já, případně někdo jiný, kdo by to byl schopen vzít za mě.

1. část

Uživatel zažádá o vytvoření nového webhostingu (například z adresy alik.cz/w (w jako webhosting)) úplně stejně, jako třeba o přejmenování a spojení účtu, vydání nového článku, vtipu, atd. Tato žádost pak už bude jen a pouze čekat na to, až ji někdo ze správců schválí (pro ještě větší bezpečnost by se tyto žádosti mohly schvalovat pouze ze serveru alik.cz, ale to už nechám pouze a jenom na vás).

2. část

V případě, že se žádost o vytvoření nového webhostingu schválí, tak se pošle požadavek na vzdálený server (v našem případě virtuální privátní server), kde se pak spustí automatický proces vytváření nového webhostingu pro uživatele.

Pokud bychom se chtěli zcela vyhnout klasickému ověřování na základě hesel, mohli bychom použít poměrně nový způsob, a to ověřování na základě certifikátů a klíčů. Na vzdálený server by se tak bezpečnou cestou poslalo pouze uživatelské jméno (přezdívka) a případně pro některé účely i ID uživatele v databázi (pořadové číslo). Co se týče hesla do databáze, tak to by si pak uživatel mohl nechat automaticky vygenerovat.

V minulosti jsem už jednou jeden takový server celý sám nakonfiguroval a později i sám spravoval, a nemám tím pádem tak vůbec žádný problém něco podobného vytvořit i zde pro Alíka. Jen bych k tomu potřeboval dostat oprávnění.

Je třeba si ale také uvědomit, že v našem případě se nebude jednat pouze o konfiguraci jednoduchého webového serveru, ale rovnou o konfiguraci celého webhostingového serveru, která je nejenom velice složitá, ale i poměrně dost časově náročná. Jinými slovy to prostě nebude hned a nějaký čas to tak ještě potrvá, než se celý projekt uvede do provozu.

Osobně bych tak (vzhledem k mnou zamýšlenému modulárnímu designu tohoto projektu) spíše doporučoval nejdříve vytvořit jen jakýsi pevný základ v podobě standardizované architektury založené na kompletním softwarového zásobníku L.A.M.P, který zatím bude fungovat, a na kterém by se pak později dalo stavět a přidávat nové moduly, například v podobě nových jazyků pro skriptování a tvorbu dynamických webových stránek na straně serveru.

~Tux

A na doméně koalik.cz by mohl být odkaz na cosi, jako je whois formulář, který by mohl na tyhle stránky s informacemi o doméně přesměrovávat.

YOYO: Já bych byl pro {cokoliv}.koalik.cz. Jak se bude {cokoliv} kontrolovat, to mi nepřipadá jako problém, který by potřeboval nyní vyřešit a který by měl nějaké složité řešení.

Nechceme, aby někdo zaplácnul přezdívku jiného aktivního uživatele?
– To jde strojově ověřit.

Nechceme, aby název webu byl nějak nevhodný?
– To jde ručně vyhodnotit.

Nechceme, aby vznikl na Alíkovi nový účet nazvaný podle již existujícího webu na Koalíkovi?
– Nevím, to je nám asi celkem fuk.

„Jako způsob ověření (pro běžné uživatele) komu patří který web by stačilo mít nějaký seznam webů a autorů na koalik.cz?“
Ano. Byl by tam nějaký základní rozcestník. Potom třeba na koalik.cz/cokoliv by mohl být nějaký přehled o webu cokoliv – autor, základní popis, čas vzniku, čas poslední změny, zdrojáky…

To mi asi přijde nefér vuči lidem, kteří mají méně kryptické přezdívky.

Myslím, že by bylo pro správce těžké najít tu hranici - každý by to asi cítil trochu jinak. Co třeba takové slovo martin. Je to ten Martin, nebo jen prostě jméno Martin?

Buď bych to povolil všem a nebo zakázal všem.

A nebo překomplikované řešení:

Měsíc před spuštěním hostingu by všem přišel od Koalíka dopis:
Brzy budeme spouštět můj hosting, kde bude možné založit si libovolnou doménu. Pokud Ti vadí aby někdo používal doménu s tvou přezdívkou, nárokuj si tuto doménu pro sebe - nikdo jiný ji pak nebude moci použít - nárokování by byl jen nějaký přepínač v nastavení, člověk by tu subdoménu nemusel sám využívat.

Tím se docala omezí výběr domén, protože je tu spoustu přezdívek co se nevyužívají. Lepší by bylo, aby správci u žádosti zkontrolovali, jestli to není nějaká jasná přezdívka, protože když chce někdo provozovat web o světle, tak může použít doménu svetlo.koalik.cz, přeztože exiztoval uživatel SVETLO, zatímco třeba majdula2000.koalik.cz ne, protože je jasné že je tím myšlenu majdula.

lékařský,
uvažoval jsem stejně - asi by bylo férovější, kdyby {přezdívka}.koalik.cz bylo vyhrazene jen pro majitele té přezdívky. Co mě k tomu ale ještě napadlo je, že:

Pokud by si člověk nesměl založit {cizí přezdívka}.koalik.cz, tak pak by se taky zároveň při registraci nového Alíkovského účtu musely kromě existujících přezdívek na Alikovi kontrolovat i existující subdomeny na Koalíkovi

To už mi přijde jako takové přílišné provazování těch dvou serverů.

Co si o tom myslí –MM–?

Na html/css seriál se těším!

{cokoliv}.koalik.cz by mohlo dobře simulovat to, jak normálně fungují domény. Že je nutné je registrovat a nelze přebrat aktuálně registrovanou doménu (pokud se neuvolní). Ale stejně by tam asi byla nějaká pravidla nad rámec běžných standardů domén, že? Doména alik.koalik.cz by asi neměla být přístupná. Stejně tak možná kterákoliv cizí {prezdivka}.koalik.cz. Možná i to přebírání uvolněných subdomén by mělo být blokováno? Mají se vůbec opuštěné subdomény uvolňovat?

Jinak už dlouho bych chtěl napsat pro Alíkoviny sérii článků o začátcích v HTML/CSS. Myslím, že zprovoznění Alíkova webhostingu by mohlo být něco, co by tuhle sérii mohlo odstartovat. Když už budeme mít webhosting, tak by bylo poměrné podivné odkazovat Alíkovce, aby se to naučili jinde... aspoň ten začátek.

YOYO:

„Místo FTP bych raději použil SFTP, a vynutil aby uživatele používali ssh klíče namísto hesel. Méně pokročilí uživatelé by mohli pro nahrávání/editací souborů používat rovnou webové rozhraní.“

FTP přes protokol SSH („SFTP“) nemá vůbec nic společného s původním protokolem pro přenos souborů. V podstatě se jedná o zcela odlišný protokol, který běží a je vystavěný přímo nad protokolem SSH, původně ale určenému k úplně jiným účelům, než je přenos souborů.

Navíc nejnovější verze OpenSSH v sobě mají chybu, která zamezuje kontejnerizaci FTP uživatelů ve svých domovských adresářích a umožňuje jim tak procházení stromu až k samotnému kořenu souborového systému (nedávno jsem to na jednom serveru sám řešil).

Osobně bych tak spíše doporučoval použít původní protokol pro přenos souborů, zapouzdřený úplně stejně jako protokol pro přenos hypertextových dokumentů, v kryptografických protokolech SSL, anebo TLS.

„Jelikož si přeji podporu node.js, tak stejně bude žádoucí, aby měl každý uživatel svůj systémový účet, protože kvůli bezpečnosti nechceme, aby uživatelské programy běžely pod společným účtem.“

Node.js se pro implementaci architektury založené na kompletním softwarovém zásobníku L.A.M.P upřímně zrovna moc nehodí.

Své využití spíše nachází v implementacích architektur, založených na nekompletním softwarovém zásobníku M.E.A.N, případně jeho variantách M.E.R.N a M.E.V.N (MongoDB, Express.js, AngularJS/Angular/React/Vue.js a Node.js).

Ale samozřejmě klidně může být, jen už to nebude tak elegantním a čistým řešením, ale spíše kombinací obou dvou řešení zároveň, ale v podstatě proč ne.

YOYO:
{cokoliv}.{přezdívka}.koalik.cz my přijde moc dlouhé, já bych dal jen to {cokoliv}.koalik.cz

u ověřování by to chtělo něco, kam uživatel zadá web a ono to ukáže přezdívku. každý už by si mohl zvolit, jestli na tento seznam (s předvyplněným webem) odkáže z patičky, nebo tak.

Tux,
principiálně souhlasím, až na nějaké drobnosti.

API request na vytvoření hostingu pro uživatele nebude volany z prohlížeče uživatele, ale ze serveru Alika.
Žádost na vytvoření napřed musí někdo schválit.

Žádné heslo se posílat nebude. S hesly bych pokud možno nikde nepracoval (ale nejspíš bude třeba nějaké pro přístup uživatelských scriptů k uživatelské databázi)

Request posílaný mezi serverem alíka a serverem koalika bude buďto obsahovat nějaký API klíč, a nebo bude pomocí nějakého klíče podepsaný.

K hostingu se bude uživatel přihlašovat (nebo lépe autentizovat) skrze Alika (ve stylu OAuth) - podobný způsob autentizace už funguje u stolu s piancem - tzn. taky nějaké podepsání dat pomocí tajného klíče, akorát způsob předání dat bude jiný - pomocí přesměrování.

Přezdívka uživatele se může měnit, bude lepší posílat a ukládat i id uživatele (to neviditelné číslo, které má každý vlevo na vizitce).

Místo FTP bych raději použil SFTP, a vynutil aby uživatele používali ssh klíče namísto hesel. Méně pokročilí uživatelé by mohli pro nahrávání/editací souborů používat rovnou webové rozhraní.
Jelikož si přeji podporu node.js, tak stejně bude žádoucí, aby měl každý uživatel svůj systémový účet, protože kvůli bezpečnosti nechceme, aby uživatelské programy běžely pod společným účtem.

–MM–,
Pokud umožníme uživatelům 3 následující typy domén:
{přezdívka}.koalik.cz
{cokoliv}.{přezdívka}.koalik.cz
{vlastní doména}

({přezdívka} by byla upravená forma bez diakritiky, kterou mají nyní uživatele v URL svých vizitek)

tak myslíš, že to taky bude svádět k vytváření více alikovskych účtu, protože druhá možnost je moc dlouhá a třetí stojí peníze?
Chceme raději umožnit
{cokoliv}.koalik.cz
?

To {cokoliv} by asi mělo projít schválením v obou případech, že?

Jako způsob ověření (pro běžné uživatele) komu patří který web by stačilo mít nějaký seznam webů a autorů na koalik.cz ?
Nebo bys to chtěl mít nějak vynuceně uvedené přímo v tom webu uživatele?

–MM–:

„Pro jistotu zopakuji, že trvám na tom, že musí být možné, aby jeden účet z Alíka měl víc různých webů.“

To už je pouze konvence pojmenování schémat URI. Základní princip skriptu však zůstává prakticky stejný (je v podstatě jedno, jestli pro uživatele vytvoří jeden, anebo hned dva weby na serveru ).

„Také bych chtěl webový prohlížeč/editor zdrojáků, jak jsem popisoval před dvěma roky. Jedním z cílů je přimět k programování webů i děti, které nemají počítač.“

Pokud jde pouze o zobrazení a stahování zdrojových kódů serverové části webu, tak to klidně může obstarávat přímo webový server (ve výsledku by to vypadalo asi nějak takto). Samozřejmě to jde i nějak nastylovat, ale to už není zas tak podstatné.

Velikou výhodou webového serveru Apache jsou soubory htaccess, které v podstatě fungují jako podmnožina globálního konfiguračního souboru httpd.conf. Uživatelé si je mohou vytvářet sami, a udělit tak neoprávněný přístup pouze do adresářů, kde se nenacházejí jejich skripty s přihlašovacími údaji například k databázi.

Nad tím editorem se ještě zamyslím, ale pro úplný začátek si myslím, že je to spíš asi něco tak trochu navíc.