- Íme az új Android Auto!
- Vodafone mobilszolgáltatások
- A Mobvoi eddigi legkeményebb órája a TicWatch Atlas
- Milyen okostelefont vegyek?
- Nothing Phone 2a - semmi nem drága
- Samsung Galaxy Z Fold5 - toldozás-foldozás
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Lesifotón és renderképen a Huawei Mate 70 Pro
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy Watch5 Pro - kerek, de nem tekerek
Új hozzászólás Aktív témák
-
#20201
Gergello
addikt
instantwater
#20200
Gergello
addikt
válasz
instantwater
#20200
üzenetére
Hírlevélre a sendinblue-t használom, gondolkoztam már, hogy esetleg ezekre az action emailekre vagy nem tudom minek nevezik ott is meg lehetne próbálni.
-
#20202
instantwater
addikt
Gergello
#20201
instantwater
addikt
válasz
Gergello
#20201
üzenetére
Azt hiszem tranzakciós emailnek hívják ezeket.
Bármelyik szolgáltatás jobb, mint a szerverről közvetlen, hiszen ők abból élnek, hogy célba érjen az email, ügyelnek a spamlistákra, hitelesítésekre, stb.
Még talán a csatolmány kérdés is egycsapásra megoldódik.[ Szerkesztve ]
-
#20203
coco2
őstag
instantwater
#20200
coco2
őstag
válasz
instantwater
#20200
üzenetére
Merthogy azok a szolgáltatások nem ugyan úgy szerverről küldenek?
Spamlistára az kerül, aki marhaságokat írogat levélben. Aki érdekes tartalmat küld, azokat nem spam listára rakják, hanem már besózva fogják várni, mikor érkezik meg a következő üzenet is. Akkor is, ha php mailer küldi.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20204
instantwater
addikt
coco2
#20203
instantwater
addikt
Nem egészen ilyen egyszerű.
Nem mindegy milyen szerverről, és hogyan küldik az emailt.Azok a szerverek kifejezetten megbízhatónak vannak jelölve a spam adatbázisokban.
A saját szerverrel az a gond, hogy semmilyen adatbázisban nincs benn az IP címe. Itt már kap egy fekete pontot az email.Aztán nézz utána az SPF, DKIM, DMARC és kapcsolódó kulcsszavaknak, amelyek segítik a címzett kiszolgálót abban, hogy megállapítsa tényleg a feladó domain tulajdonosa küldte-e az emailt, vagy csak valaki spoofolja a feladót egy random szerverről.
Ezek a szolgáltatások aláírják a kimenő emailt egy kulccsal amit egy domain TXT rekord alapján vissza tud ellenőrizni a címzett.
És persze az sem mindegy, ha a te domainedről küldesz mondjuk 100 emailt gmailes címekre abból egyvalaki rákattint a spam gombra. Máris 1% spam értéke van az IP címednek. A fizetős szolgáltatások pedig milliós nagyságrendben küldenek, tucatnyi IPről. Egy-egy spam jelölés nem nagy gond.
Gondolod, hogy csak a hülye, lusta, pénzes embereknek találták ki őket?
Javaslom nézz utána az email deliverability témakörnek.
[ Szerkesztve ]
-
#20205
disy68
aktív tag
instantwater
#20204
disy68
aktív tag
válasz
instantwater
#20204
üzenetére
zárójelben annyit azért hozzátennék, hogy ezeknél a bulk email szolgáltatóknál is vannak 'shared ip' csomagok, ahol osztozik az ember több felhasználóval és ha ők spam-elnek, akkor pórul lehet járni és fel lehet kerülni önhibánkon kívül is spamlistára, erre érdemes lehet még figyelni
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
#20207
instantwater
addikt
disy68
#20205
instantwater
addikt
válasz
disy68
#20205
üzenetére
Osztoznak, persze.
De pontosan ezért fizetsz, hogy ezt figyeljék, és fenntartsák az IP reputációját.És mivel hitelesítve van az email a korábban említett módokon, végső soron a domain kerül tiltólistára, nem az IP.
Hiszen az adott IPről érkező levelek mondjuk 0.1%-a kerül mondjuk spamnek jelölésre, viszont az adott domain mondjuk 20-30%-a, hiába jön több IPről, akkor a spamfilterek szépen kiszűrik az egész domaint.Illetve ott hasal el az egész dolog, hogy ezeknek a küldőknek a szerződésében benne van, hogy tilos a spam. Ha valaki spammelésre használja, kitiltják.
De leginkább el sem jutnak eddig, hiszen nem biznisz fizetős spamet küldeni.Olcsóbb feltört szerverekről scripttel küldeni.
És akkor itt vissza is érkeztünk a start mezőre.
Ne küldj szerverről emailt, mert zéró reputációd van.[ Szerkesztve ]
-
#20208
coco2
őstag
instantwater
#20204
coco2
őstag
válasz
instantwater
#20204
üzenetére
Nagyon sok website, ahol hírlevélre iratkozom fel, eleve figyelmeztet, hogy az első levelet ellenőrizzem a spam mappában, és jelöljem ki onnét. Azt megteszem, hiába van spam filteren a domain, meg fogom kapni az összes mailt. Akit érdekel, mind megkapja. Akit meg nem, azt úgysem tudod megerőszakolni. Hiába regisztrálsz bármilyen nyilvántartásban - igen, szerintem az tisztán pénz lehúzás, semmi egyéb - ha az adott felhasználó berakott téged a saját spam filterébe, akkor annak a felhasználónak többet nem küldesz mailt. Végső soron a személyes beállítások dominálnak. A mindenféle nyilvántartások csak az alapértelmezést adhatják meg, amíg személyesen az adott címzettől nyilatkozat nem születik arra, hogy kíváncsi-e arra a küldőre, vagy sem. Én nem változtat azon semmiféle hiúság vására, mert a gdpr sokkal durvábban büntethet egy visszaélésért, semhogy megérné.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20210
coco2
őstag
instantwater
#20209
coco2
őstag
válasz
instantwater
#20209
üzenetére
Gizimanci majd odahívja a 8 éves kisunokáját, aki még épp csak megtanult olvasni, de egy tablettel már elboldogul, és majd ő segít.
A vásárlási hírlevelek egyébként tipikusan a spam mappában landoló levélszemetek. MErt az nem letörlés, az spam. Bezzeg ha egy fiatal szőke lány üzen rád, azt minimum elolvasod, mielőtt letörlöd - spam mappába akkor sem kerül. Inkább nekik fizetnéd a pénzt, mint a semmire kellő hitelesítő bizottságosdinak
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20211
disy68
aktív tag
instantwater
#20207
disy68
aktív tag
válasz
instantwater
#20207
üzenetére
Nem, ez saját tapasztalatat a Sendgrid-del. Náluk a shared ip csomagnál (Essentials), ha valaki spamel, az megölheti szinte az egész ip pool-t (tizenvalahány ip-ből spamlistára került kb. 8), nem csak a domaint.
És hiába fogják őket letiltani, ha közben napokig áll a szolgáltatás, mert egyes spamlistákról nem kerül le az ip időben. Itt az is benne van a pakliban, hogy valaki nem tényleges spam-et küld csak annak értékelt levelet akár tartalom, akár címzettek alapján, esetleg véletlenül valami bug következtében. Mi ezért váltottunk náluk dedikált ip-s csomagra nemrég, mert így jártunk. El tudom képzelni, hogy máshol is előfordulhat hasonló.
#20208 coco2
Nem tudom milyen "website"-ok ezek, de bárhol ilyet olvasol az komolytalan vagy szimplán igénytelen. Az meg senkit sem érdekel, hogy valaki milyen személyes szűrést használ vagy sem, ami számít, hogy pl. a google vagy bármilyen nagyobb szolgáltató ne tiltsa az összes küldendő leveledet kapásból, mert az bizony tud fájni az üzletnek.[ Szerkesztve ]
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
#20212
Gergello
addikt
instantwater
#20202
Gergello
addikt
válasz
instantwater
#20202
üzenetére
A sendinblueról küldött beágyazott képet tartalmazó emailnél a gmail ugyanúgy megjeleníti csatolmányként a beágyazott képeket. Akkor ez mégsem hiba, hanem a gmail sajátossága ?
Saját címemnél nem jeleníti meg csatolmányként, csak ennél az újonnan regisztráltnál. -
coco2
őstag
válasz
disy68
#20211
üzenetére
Nincsen olyan, hogy alapból "letilt". Ne dimenzionáljuk már túl a realitást. Ha a felhasználó részéről nincsen döntés, akkor alapértelmezést használ a levelező, és azt tudod befolyásolni, hogy az mi legyen. Az lehetségesen spam lesz. A levél akkor is megérkezik.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
disy68
aktív tag
Én értem, hogy nem találkoztál ilyennel még, de légyszives legalább nézz utána előbb kicsit. Van olyan, hogy gmail-re küldött levelet visszadob a szerverük (reject), ami nem kerül a spam folder-be sem. Egyéb feketelisták.
“Yeah, well, you know, that’s just, like, your opinion, man.” — The Dude
-
coco2
őstag
Cookie kezelési technikára szeretnék tippet kérni.
A website egyedül session id-t pakol cookie-ba, minden info szerver oldalon van mentve. Php.ini-ben be lesz kapcsolva a httponly.
A session cookie azonnal a felhasználó gépére kerül, amikor a website-ot megnyitja. A webszerver azonnal küldi, és általában nem vár gdpr tájékoztató elfogadására. A gdpr meg azt mondja - amennyire én értelmezni tudom - hogy felhasználói beleegyezés nélkül nem illik cookie-t küldeni a gépére. Vagy rosszul értelmeztem valamit?
Ha tévedésben élek, egy felvilágosításnak örülnék, vagy ha van egy remek jó blog róla, akkor egy linknek. Köszönöm.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
supercow
őstag
Itt van róla szó. A lényeg, hogy önmagában a session cookie alapján nem lehet egy személyt azonosítani, illetve az hogy consent előtt adja a szerver a “legitimate interest” elv alapján indokolt, vagyis a user eleve önként jött az oldalra. Privacy policy mindenképp tegyen róla említést. De persze nem vagyok eu jogász, nem tudhatom az abszolút igazságot
In nomine Pasta, et Fusilli, et Spaghetti Sancti. Ramen.
-
coco2
őstag
Ti szoktatok írni terms of service-t, amikor "full stack" fejlesztetek?
Igyenesen használható website-hoz lopnom kellene egy normális disclaimert nemzetközi gyakorlathoz. Jellegében fénykép megosztó site. PErsze vannak olyanok weben, és éppen ollózok, de ha valakinél van kéznél jogi stuff framework megoszthatóan, annak is örülnék.
(Privacy policy már kész, találtam hozzá normális nyersanyagot, és azt megírtam, köszönöm hozzá a fentebbi tippeket is, bekalkuláltam azokat is.)
[ Szerkesztve ]
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
Újfent fogalmazási nehézségeim akadtak jogi anyaggal - ToS.
Jó lenne egy példa, ahol a szolgáltatás rá van építve 3rd party szolgáltatóra is, és a ToS-ban kikötik, hogy a szolgáltatás használatához annak a szolgáltatásnak a pontjait is el kell fogadni - mindezt persze angolul megfogalmazva.
Próbáltam olyan példákat nézni mint a facebook-hoz tartozó alkalmazások de sajna azoknak már a jogi anyagaik is be vannak építve a facebook-ba. Nem sikerült olyan website-ot találnom, ahonnét koppanthatnék részletet a ToS-ból ezügyben. Freeware legal pages generátorok között nem találtam ilyesmire támogatást
Ha véletlenül valaki ismer olyan site-ot, ahonnét koppanthatok, egy linknek örülnék.
Köszönöm.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
coco2
őstag
Van arra valami kitalálva, hogy szerverenként befolyásolni tudjam az új session nevek létrehozását?
Ha load balancer mögött több külön szerver akármelyike megkaphat egy már létező munkamenetet másik szerverről, akkor tudnom kellene oda irányítani a felhasználót, ahova eredetileg tartozott. Nem bonyolult megtenni, ha tudom, hogy hova irányítsam. Ha befolyásolni tudom az új session nevek létrehozását, egy szerverenként egyedi előtag beszúrása és azonosítása meg is oldaná a problémámat.
Ha van erre valami más kitalálva, blog linknek örülnék, mit olvasgassak.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20226
instantwater
addikt
coco2
#20225
instantwater
addikt
Ezt úgy hívják sticky-session, és a loadbalancernek kell támogatnia. Így minden requestet ugyanarra a szerverre fog irányítani ahová a legelsőt irányította amit az adott klienstől kapott.
Javaslom ne szórakozz a session nevek befolyásolásával. Nagyon mély gödör, és csak még több fejfájást generálnál magadnak.
Gyanítom azért van erre szükséget mert mindegyik szervereden fut egy-egy adatbázis másolat.
Erre az a megoldás, hogy minden szerveredről ugyanazt, a központi adatbázist használod, így mindegy melyik szerver kapja a kérést, a sessionok egy helyen, az adatbázisban lesznek. Extra haszonként még azt is megkapod, hogy bármikor lecserélheted bármelyik szervered adatvesztés nélkül. -
#20227
coco2
őstag
instantwater
#20226
coco2
őstag
válasz
instantwater
#20226
üzenetére
És a gödör még annál is mélyebb, mert nem használhatok egy darab központi adatbázist
Olyan sok terhelést kapna, hogy muszáj őket elosztanom.A sticky session nevet köszönöm, körbeszaglászok. De megoldást jelenteni csak akkor fog, ha a load balancereket mind flottába állíthatom olyasmit kezelni. Mert az a helyzet, hogy load balancerből is több lenne.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20229
coco2
őstag
instantwater
#20228
coco2
őstag
válasz
instantwater
#20228
üzenetére
Bár csak az indexek miatt kellene aggódnom
Memory engine-t azért használok, mert az fel tud írni másodpercenként és táblánként külső forrásból kb 2-3 ezer rekordot egy 2 ghz-es cpu-n (kommersz szerverek esete ugye). Szerencsére a sebesség igazi korlátja mindössze a table lock, ahol a folyamatok összeakadnak, szóval ha elérem a korlátot, gyártok majd arra round robin osztást, hogy a folyamatok eltérő táblákat használjanak. Mondjuk 16 memória táblára osztani szét a terhelést. Azok tudnak futni külön szálakon, és nem akasztják egymást. Nekem ott kezdődik a terhelés fogalma. Hdd-n, ssd-n mindaz esélytelen lenne alapos write-back system cache nélkül, de azt viszont nem tudom annyira kézben tartani, mint a memory engine táblákat.Load balancer annyiban probléma, hogy mindegyik load balancer ugyan azt a szerver csoportot éri el. Gondold csak végig, mi azzal a bajom, ha nem közös nyilvántartással teszik mindazt.
Ha a sticky session találmány nem lenne elég, jól sejtem, hogy csak a session_set_save_handler() marad? Vagy van még valami más, amit utolsó esélyként szintén megnézhetek, mielőtt a nyuszi üregének a legalján állok neki gödröt ásni?
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20230
instantwater
addikt
coco2
#20229
instantwater
addikt
A Facebooknál dolgozol, vagy hol van ekkora terhelés ami ilyen egyedi megoldásokat kíván és ráadásul PHPben?
Esetleg a Redis opció lehet a több tábla helyett?
Vagy esetleg táblapartícionálás? Clustering, sharding?Miért kellene több loadbalancer? Egy loadbalancer feladata, hogy minimális overheaddel továbbítsa a lekérést. Kell neki sok CPU, RAM, és jó nagy sávszél, aztán mehet. Jobb helyeket van menedzselt loadbalancer ahol neked nem kell foglalkoznod a méretezéssel.
-
#20231
coco2
őstag
instantwater
#20230
coco2
őstag
válasz
instantwater
#20230
üzenetére
Nem dolgozom a Facebook-nál. Bár tekintettel rá, hogy a licencelés szerint egy befutott alkalmazást elkövetelhetnek, még az sem kizárt, hogy az a jövőben megváltozik. Elvileg 5M mau-nál húznak korlátot, amikor rám szólhatnak hogy nosza, akkor most valamit tenni kellene. De addig előbb el is kell ám jutni
A php alábecsülését nem igazán értem. Nekiállsz alaposan kiszámolni mindent egy teljesítmény webapp fejlesztésében, a php-n kívül én nem is találtam semmi mást, amiben megbízni mernék.
Redis egy szálon fut. Nem tudták megoldani a srácok a multithreadinget. A motor legalján pont annyit tudhat teljesíteni, mint mysql memory engine 1 táblán.
Több loadbalancer ofc azért kell, mert egy fürtben a load balancer is ki tudhat esni. És akkor mi is történik? Meghalt az egész alkalmazás?
Eltértünk a tárgytól
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20232
instantwater
addikt
coco2
#20231
instantwater
addikt
PHP alábecslést arra alapozom, hogy blocking végrehajtást alkalmaz, szemben mondjuk a Node.js-sel.
Illetve adatbázis kapcsolatok kezelése elég pazarló PHPben, mert minden lekérdezés egy új adatbáziskapcsolatot kell, hogy nyisson, szemben egy olyan alkalmazással ami önmaga kezeli a lekérdezéseket és tudja menedzselni az adatbázis connection poolt, így kevesebb kapcsolódással újra tudja hasznosítani a kapcsolatokat több egymástól független lekérdezéshez.
-
#20233
coco2
őstag
instantwater
#20232
coco2
őstag
válasz
instantwater
#20232
üzenetére
És mi a baj a blocking végrehajtással? Lehet azt is ügyesen használni.
Már régen nem a php 3 időket éljük. Van perzisztens kapcsolat php-hoz.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20234
instantwater
addikt
instantwater
addikt
Eszembe jutott, hogy attól, mert nagy az adatbázis és trükközni kell, attól még talán mégis érdemes lenne külön szerverre tenni, és leválasztani a PHP-t futtató szerverről, így lenne esély ugyanazt az adatbázist használni több PHP szerverről.
Vagy abszolút nem megvalósítható?
-
#68216320
törölt tag
Sziasztok.
Php konfigurálásban szeretnék segítséget kérni.
Nginx-et használok php7.4-el.
Phpinfo() szerint az /etc/php/7.4/fpm/php.ini fájl van betöltve.
Ebben átírtam, hogy minden error miatt szóljon (E_ALL) és jelenítse meg (display_errors = on).
Mégsem jelenik meg.
A default (localhost) domain alatt dolgozom egy alkönyvtárban.
Mit rontok el? Hogyan tudnék hibaüzenetet kicsikarni tőle?(nginx error.log-ban megjelenik a hibaüzenet)
[ Szerkesztve ]
-
#20239
coco2
őstag
instantwater
#20234
coco2
őstag
válasz
instantwater
#20234
üzenetére
Abban a design-ban egy gépre szorul az adatbázis, és bármennyit optimalizálok, legkésőbb 100k mau környékén ott a plafon.
Tervben van, hogy ha muszáj ideiglenesen áttérni egy szerverről kicsit többre, ofc a db mehet külön, és talán 2-3 php szervert ki tud szolgálni, arányaiban annyi lehet a cpu eltérés közöttük. De jobb szeretném azt a tervezési lépést mindenestül átlépni. Felemás megoldás, aminek minden baja van és semmiben sem igazán jó.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
#20241
coco2
őstag
instantwater
#20240
coco2
őstag
válasz
instantwater
#20240
üzenetére
A terveket illetően igazán köszönök bármilyen építő jellegű kritikát. A magam részéről úgy vélem, éppen azokkal az extrém kérdésekkel tuti jól fogok szerepelni a megmérettetések során
Helyette a session kezelési technikák volt az egyetlen kérdés, ami úgy elúszott, mint ami sose volt itt
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Mike
veterán
Sziasztok
A következő anomáliába futottam bele, ami lecsupaszítva a következő:
Adott egy index.php amiben van egy véletlenszám generátor, amit beteszek egy session változóba. adott egy másik file ami var_dump-pal kiírja a session tömb tartalmát.
A jelenség a következő: chromiumos böngészők alatt, a szám lekérdezésenként változik.
Firefox alatt csak akkor ha az index.php-t is futtatom. Ha átnevezem az index.php-t a chrome alatt is abbamarad a jelenség.
Mi lehet ez? Valami nginx beállítási probléma?[ Szerkesztve ]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest