Archívum - Dec 2018
december 31
A GDPR hogyan áll a fekete listákhoz?
Felmerült egy topicban, hogy mit csináljon a webshop gazdája, ha szivatják az ügyfelek, és pl rendelnek 3 videokártyát, aztán visszaküldik mindet elállással miután kitesztelték. Sok helyen egy idő után ilyenkor fekete listára teszik az illetőt. Ameddig eljutottam ezzel kapcsolatban, hogy valószínűleg a "jogos érdek" a jogalap ilyenkor az adatgyűjtésre, és elég jelenteni, nem kell külön engedélyt kérni rá, illetve nem muszáj törölni sem senkit a fekete listáról, ha kéri akkor sem. Azt írták máshol, hogy a jogszabályok előírják ennél a jogalapnál, hogy csinálni kell egy érdekmérlegelési tesztet. Ez a gyakorlatban hogyan néz ki? Csináltatok már ilyet?
■ Spamrobot vagy ?
Szevasztok !
Hozzászólás végén arra a kérdésre kéne válaszolni "Spamrobot vagy?".
Nos ennél a pontnál nem jutottam tovább, ugyanis nem tudom, mit kéne válaszolnom.
Ez így elég gáz (FF és Chrome alatt is).
Most már látom, tök mindegy, mit ír be az ember, de ez így akkor is gáz.
■ Hozzászólás végén arra a kérdésre kéne válaszolni "Spamrobot vagy?".
Nos ennél a pontnál nem jutottam tovább, ugyanis nem tudom, mit kéne válaszolnom.
Ez így elég gáz (FF és Chrome alatt is).
Most már látom, tök mindegy, mit ír be az ember, de ez így akkor is gáz.
Kliens IP címe
Nem tudom, szerver- vagy kliensoldali probléma: logolni akarom a kliensek IP címét, hogy az illető később vissza tudja nézni, milyen IP-kről jelentkezett be a szolgáltatásba.
Hányféle módszer van a kliens IP címének begyűjtésére?
A kérdés eredete: több webes e-mail szolgáltatónál van ilyen lehetőség, hogy listázzam, milyen címekről léptem be. A legtöbb helyen a valós WAN címem szerepel. Kivéve, ahol nem mindig... mert ha a lokális proxy-mat (squid - ahogy felmegy ubuntun, nincs plusz konfig rajta amennyire emlékszem) használom, akkor nem a WAN címet látom ebben a listában, hanem a LAN-os címeket.
És itt egy kicsit vakarom a fejem, hogy ezt akkor most mégis hogyan...
Megfelelő, neten lévő szerver hiányában nem tudok tcpdump-ot készíteni a forgalomról, nem látom, miért találja meg az egyik a LAN-os címet és miért látja a másik a valódit...
■ Hányféle módszer van a kliens IP címének begyűjtésére?
A kérdés eredete: több webes e-mail szolgáltatónál van ilyen lehetőség, hogy listázzam, milyen címekről léptem be. A legtöbb helyen a valós WAN címem szerepel. Kivéve, ahol nem mindig... mert ha a lokális proxy-mat (squid - ahogy felmegy ubuntun, nincs plusz konfig rajta amennyire emlékszem) használom, akkor nem a WAN címet látom ebben a listában, hanem a LAN-os címeket.
És itt egy kicsit vakarom a fejem, hogy ezt akkor most mégis hogyan...
Megfelelő, neten lévő szerver hiányában nem tudok tcpdump-ot készíteni a forgalomról, nem látom, miért találja meg az egyik a LAN-os címet és miért látja a másik a valódit...
december 28
Hogyan mondanátok, hogy garantált/ellenőrzött a környezet?
Irok éppen egy kódot, aminél van választási lehetőségem, hogy egyszer ellenőrzöm az elején a környezetet egy scenario-val, aztán ha azon átmegy a kód és nem szór UnsupportedEnvironment-et, akkor utána abból indul ki, hogy a környezet rendben van, és nyugodtan elvárhatja, hogy bizonyos dolgok rendben működnek anélkül, hogy állandóan try-catch-be kellene tenni őket. A másik lehetőség, hogy teleszórom a kódot assertion-ökkel meg try-catch-el, és folyamatosan ellenőrzök, viszont attól elég ronda és olvashatatlan lesz az egész. Az első megoldás mellett döntöttem, viszont szeretnék az EnvironmentCheck-nél valami kifejezőbb nevet adni neki, ami tükrözi azt, hogy garantálva van a környezet és nyugodtan dolgozhat a kód. Az érdekelne, hogy van e erre valami bevett minta jól átgondolt elnevezésekkel, valami assurance vagy guarantee, vagy ilyen szókészletre gondolok? Esetleg ha nincs, akkor csináltatok már ilyet úgy, hogy nem checker-nek neveztétek?
■ december 27
A websocket vajon mi? :)
Szóval mi is ez tulajdonképp?
O.K., addig tiszta, hogy egy kétirányú/duplex kommunikációra alkalmas eszköz.
De mitől "web"?
Amit eddig láttam belőle, annak alapján ugyanolyannak tűnik, mint bármely más socketes kommunikáció.
ui: ha a cím ismerős lenne valahonnan... https://www.youtube.com/watch?v=6aabdiJkxcw (de óvatosan, a megnyitás agykárosodást okozhat! ;) )
■ O.K., addig tiszta, hogy egy kétirányú/duplex kommunikációra alkalmas eszköz.
De mitől "web"?
Amit eddig láttam belőle, annak alapján ugyanolyannak tűnik, mint bármely más socketes kommunikáció.
ui: ha a cím ismerős lenne valahonnan... https://www.youtube.com/watch?v=6aabdiJkxcw (de óvatosan, a megnyitás agykárosodást okozhat! ;) )
december 25
változtatható hátterszínű png kép nem kívánt kerete
Sziasztok !
Egy változtatható hátterszínű png (transzparens) képpel gyűlt meg a bajom,
ugyanis a kép körül egy vékony keret látható, amit sehogy sem sikerül eltűntetnem.
Azt szerettem volna elkerülni a fenti megoldással, hogy ne kelljen 2 képpel dolgozni.
Előre is köszönöm a segítségeteket.
■ Egy változtatható hátterszínű png (transzparens) képpel gyűlt meg a bajom,
ugyanis a kép körül egy vékony keret látható, amit sehogy sem sikerül eltűntetnem.
Azt szerettem volna elkerülni a fenti megoldással, hogy ne kelljen 2 képpel dolgozni.
Előre is köszönöm a segítségeteket.
december 22
webprog.hu
Teljesen elhalt a projekt?
Akartam küldeni pár érdekességet, amit a neten olvastam, de mindig pont olyankor, amikor épp nem volt weblabor :(
■ Akartam küldeni pár érdekességet, amit a neten olvastam, de mindig pont olyankor, amikor épp nem volt weblabor :(
december 14
2FA - ez is megkerülhető
Mivel a blogmark funkció nem működik...
arstechnica.com
Érdemes elolvasni. Úgy fest, egy-két kivételtől eltekintve, a legtöbb kétlépcsős azonosítás kijátszható. És még én vagyok paranoiás :D
■ arstechnica.com
Érdemes elolvasni. Úgy fest, egy-két kivételtől eltekintve, a legtöbb kétlépcsős azonosítás kijátszható. És még én vagyok paranoiás :D
december 10
Ért itt valaki az adatkezeléssel, -gyűjtéssel kapcsolatos jogi témákhoz?
Már a sokadik olyan fórumba botlottam, ahol a felhasználási feltételek közt nem szerepel a személyre szabott profilalkotás ténye. Ugyanakkor, hacsak nem jósnőkkel dolgoztatnak, erős a gyanú, hogy olyan adatokat gyűjtenek, amivel egyértelműen követhető a tagok kiléte. Pontosabban az, hogy x nick, y nick és z nick azonos személyhez köthető.
Érdekelne, hogy meddig mehetnek el az ilyen gyűjtögetésben, különösen a GDPR bevezetése óta.
■ Érdekelne, hogy meddig mehetnek el az ilyen gyűjtögetésben, különösen a GDPR bevezetése óta.
december 10
logbányászat manuálisan
Hátha itt valaki... :)
Adott egy k.nagy logfile (~3millió sor)
Szeretném kiválogatni belőle az ismétlődő sorokat, hogy ha ránézek a logra, azokkal ne kelljen foglalkoznom.
Elvi elképzelésem van, de a mennyiség miatt attól tartok, előbb török fel brute force-szal egy sha256-os hash-sel kódolt jelszót, mint amennyi idő alatt ebből eredmény lesz. :)
Elképzelés 1: cat journal.txt | sort | uniq -c | sort -n - az eredményből a 3-nál több ismétlődést tartalmazó sorok mehetnek a szűrőbe, ezek jó eséllyel rendszeresen előfordulnak. Aha... csak az a baj, hogy a sorok többségében van process id, eszköznév, valami random sorszám, epoch time stb.
Manuálisan kb. 700ezerre sikerült redukálni a sorok számát, a többi mind olyan, hogy valami lényegtelen változót tartalmaz.
Például (kiragadott példa, totál más eltérések vannak más típusú soroknál):
freshclam[998]: daily.cld updated (version: 24258, sigs: 1836466, f-level: 63, builder: neo)
freshclam[998]: daily.cld updated (version: 24259, sigs: 1836842, f-level: 63, builder: neo)
Itt pl. az a két verziószámféleség tér el, de előfordulhat a freshclam melletti pid változása is.
Innen jön az
Elképzelés 2:
Szavakra bontom a sorokat, eldobálom belőle a szeparátorokat és így hasonlítom össze őket... aham... persze... de milyen sorokat? Minden sort a többi három millióval? Hány hétig futna? :D
Hogy lehetne ezt kulturáltan megoldani?
Sortolni annyira nem tudom, mert mi legyen a kulcs, mikor fogalmam sincs, hol van a sorokban olyan változó, amit nyugodtan eldobhatok?
(most ez így hirtelen felindulásból íródott, könnyen lehet, hogy reggelre rájövök, mit hagytam figyelmen kívül. :) )
-----------------
Update: a fentiek előzménye, hogy a routerem logjait is őrizgetem, néha ellenőrzöm.
Adott egy k.nagy logfile (~3millió sor)
Szeretném kiválogatni belőle az ismétlődő sorokat, hogy ha ránézek a logra, azokkal ne kelljen foglalkoznom.
Elvi elképzelésem van, de a mennyiség miatt attól tartok, előbb török fel brute force-szal egy sha256-os hash-sel kódolt jelszót, mint amennyi idő alatt ebből eredmény lesz. :)
Elképzelés 1: cat journal.txt | sort | uniq -c | sort -n - az eredményből a 3-nál több ismétlődést tartalmazó sorok mehetnek a szűrőbe, ezek jó eséllyel rendszeresen előfordulnak. Aha... csak az a baj, hogy a sorok többségében van process id, eszköznév, valami random sorszám, epoch time stb.
Manuálisan kb. 700ezerre sikerült redukálni a sorok számát, a többi mind olyan, hogy valami lényegtelen változót tartalmaz.
Például (kiragadott példa, totál más eltérések vannak más típusú soroknál):
freshclam[998]: daily.cld updated (version: 24258, sigs: 1836466, f-level: 63, builder: neo)
freshclam[998]: daily.cld updated (version: 24259, sigs: 1836842, f-level: 63, builder: neo)
Itt pl. az a két verziószámféleség tér el, de előfordulhat a freshclam melletti pid változása is.
Innen jön az
Elképzelés 2:
Szavakra bontom a sorokat, eldobálom belőle a szeparátorokat és így hasonlítom össze őket... aham... persze... de milyen sorokat? Minden sort a többi három millióval? Hány hétig futna? :D
Hogy lehetne ezt kulturáltan megoldani?
Sortolni annyira nem tudom, mert mi legyen a kulcs, mikor fogalmam sincs, hol van a sorokban olyan változó, amit nyugodtan eldobhatok?
(most ez így hirtelen felindulásból íródott, könnyen lehet, hogy reggelre rájövök, mit hagytam figyelmen kívül. :) )
-----------------
Update: a fentiek előzménye, hogy a routerem logjait is őrizgetem, néha ellenőrzöm.