Fórum Root.cz
Hlavní témata => Software => Téma založeno: JurajL 20. 05. 2021, 15:15:27
-
Ahojte,
mam sluzbu, ktoru poskytujem protokolom, ktory je postaveny nad HTTP a potreboval by som riesit spoplatnovanie. Kazdy klient pristupuje v sluzbe pomocou vlastneho klientskeho SSL certifikatu a ma zaplateny urcity pocet volani sluzby. Potreboval by som vyriesit:
- aby sa pri kazdom uspesnom zavolani inkrementoval counter pre klienta (resp. pre dany klientsky certifikat)
- ked sa dosiahne nastavena max hodnota pre klienta, dalsie volania boli odmietnute
- optimalne by bolo, aby som vedel hodnotu countera danemu zakaznikovi jednoducho publikovat cez web
Nevidim zmysel to programovat, lebo predpokladam, ze to vie riesit nejaky modul do reverse proxy alebo na to musi existovat nejake ine standardne riesenie. Bohuzial, nedogooglil som sa k nicomu rozumenu.
Nejake tipy? Dakujem
-
Těžko radit přehlédl jsem co používate za SW,..
Pokud Apache tak mod_ssl poskytuje informace o certifikátech a ty se určitě dají logovat. Mod_security zase dokáže limitovat spojení. A jestli by se dali použit proměný z mod_ssl v mod_security tak to asi nějak poskládáte.
-
Vyber softu, ktory na to pouzijem, je na mne.
Intuitivne tusim, ze sa to "nejak" bude dat poskladat konfiguraciou nginxu alebo apachu. Ale viem viac o programovani ako o ich sprave. A trosku sa borim s tym ake premenne, aky modul, ako presne to skombinovat a zatial bezvysledne prezuvam dokumentaciu...
-
ja by som to implementoval priamo do tej aplikacie. Co v pripade, ak sa dana sluzba zavola, ale nebude funkcna? to je tiez potrebne tam osetrit. Takze podla mna neriesit logy, alebo nejake proxy, ale jednoducho ak vsetko prebehne ako ma, zapocitat pripojenie, resp. hned po pripojeni skontrolovat ci moze, a ak nie, tak rovno poslat napr. 402
-
ja bych byl k zakaznikum pratelstejsi, pokud prekroci limit, tak bych jim to nevypnul, ale omezil funcionalitu.
takze jim jejich sluzba neprestane fungovat, ale nejak se omezi.
-
Riešiť to na strane aplikácie nie je vhodné z viacerých dôvodov, napr.
- pri ľubovolných ďalších službách by som musel vždy upravovať ich imlementáciu
- detto pri zmene licenčného modelu
- v momente, keď využijem na poskytovanie niektorej zo služieb proprietárny produkt, kde úpravy robiť neviem, budem musieť nad ním programovať vlastnú fasádu kvôli spoplatňovaniu
Omnoho vhodnejšia sa mi zdá samostatná vrstva, kde to riešim konfiguráciu toho, čo existuje.
Co v pripade, ak sa dana sluzba zavola, ale nebude funkcna?
Predpokladám, že nejaký proxáč, api gateway (whatever použijem na sledovanie spotreby) sa bude vedieť vyrovnať s dostupnosťou služby a/alebo návratovým kódom.
ja bych byl k zakaznikum pratelstejsi, pokud prekroci limit, tak bych jim to nevypnul, ale omezil funcionalitu.
takze jim jejich sluzba neprestane fungovat, ale nejak se omezi.
To by malo zmysel pri službe, kde má má degradácia priepustnosti alebo odozvy nejaký vplyv na biznis proces zákazníka. Mám (aj) zákazníkov, ktorý ju využijú v priemere cca 1x za pracovný deň. Tohoto segmentu (= väčší počet zákazníkov pravidelne platiacich menšie sumy), by som sa nerád vzdal. Biznis model berte ,,as is", ide mi skôr o technické riešenie.
-
Aniž bych to kdy dělal, asi bych řešení hledal v Nginx + LUA script přímo v nginxu. Viz OpenResty nebo jen LUA modul pro nginx. Během požadavku má nginx k dispozici všechny údaje, které potřebujete a může v klidu počítat přístupy a informaci o nich ukládat do maličkaté (rychlé) DB.
-
Áno, toto je riešenie, ku ktorému sa mi zdá, že dospejem (nginx + skripty preň). Len ma to prekvapilo, lebo som to považoval za tak generický a bežný problém, že som predpokladal niečo priamočiarejšie (len konfigurácia, prípadne využitie nejakého existujúceho modulu).
Ale aj toto je feedback - než sa do toho pustím, mám pocit, že mi neuniklo nejaké všeobecne známe a hotové riešenie.
-
O hotovém nebo běžném řešení nevím. Co jsem kdy viděl, tak to bylo navěšeno v aplikaci a ještě k tomu hloupě - při přijetí požadavku. Řešení na webserveru (proxy) mi přijde lepší, protože dokáže vzít v potaz i to, jestli se data úspěšně doručila (nebylo přerušeno spojení apod.). Na druhou stranu, budou tam potřeba vyřešit i další situace, co můžou nastat - např. nedostupnost databáze a co dělat v takovém případě.
Taky mě často překvapí, jak na docela časté problémy neexistují řešení. Vysvětluju si to tím, že se přeci jen jedná o situace, které moc lidí neřeší - a když už, tak to vyřeší ne optimálně, ale rychle (např. v aplikaci). A ten, kdo to vyřeší dobře (najde si cestu), zase nemá žádnou potřebu to nějak zveřejňovat.
-
všeobecne známe a hotové riešenie
mno, a nedíval jsi se na ELK stack?
mě příjde že to je přesně ono..
na co bude potřeba vytáhnout klávesnici:
* nakonfení přesměrování logů z apache do logstashe (třeba přes syslog, ale mají i takový hack, "filebeat")
* základní konfig logstashe a elasticsearche
* udělání dashboardu v Kibaně
všechny tyhle věci se dají spustit prakticky z ruky v dockeru... ..možná ten logstash už ani není potřeba, teď jsem se v tom pár major verzí nerýpal..
..ten elasticsearch je samozřejmě kanón na vrabce, ale funguje to i na takové blbosti :)
EDIT: už vidím, ty tam chceš i automatickou akci.., to bude chtít naskriptovat.