- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- sziku69: Fűzzük össze a szavakat :)
- Gurulunk, WAZE?!
- Geri Bátyó: B550 szűk keresztmetszet, de mi és miért?
- sh4d0w: Csak a profit - emberélet nem számít
- vrob: Az IBM PC és a játékok a 80-as években
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
Új hozzászólás Aktív témák
-
#20300
coco2
őstag
instantwater
#20299
coco2
őstag
válasz
instantwater
#20299
üzenetére
És gondolom fizetik is az extra szakember munkaórát szép pénzen
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#20299
instantwater
addikt
coco2
#20298
-
coco2
őstag
-
Taci
addikt
válasz
pelyib
#20296
üzenetére
Szia!
Köszönöm a választ!
Egyelőre az időzóna beállítása a leggyorsabb megoldás, amit a kódban írtál is, és szépen működik is (ahogy a példádban is):
date_default_timezone_set('Europe/Budapest');Tesztelem, ha esetleg valami nem jól működne vele, akkor már megírtam a kód módosítását a
DateTimeImmutablehasználatával is.Köszönöm!
-
pelyib
tag
The Unix timestamp that this function returns does not contain information about time zones. In order to do calculations with date/time information, you should use the more capable DateTimeImmutable.
[Forras]Hasznald inkabb a DateTime classokat. Tisztabb szarazabb erzes. (esetleg a Carbon nevu libet)
[Pelda]miért megy félre a dolog, miért vonja le azt az 1 órát.
Ha minden igaz (bar en kuka vagyok az time manipulaciohoz) a PHP UTC / GMT idozonat hasznalja. -
Taci
addikt
Sziasztok!
Remélem, tudtok ebben segíteni:
Adott egy időbélyegző, pl.:
$date = "Fri, 22 Jan 2021 17:36:10 +0100";Hiába a 17:36 a pontos idő, az időzóna (+0100) miatt valamiért "elszámolja" magát, és 1 órával kevesebbet ír ki, pl.:
echo date('H:i', strtotime($date));
azt írja ki, hogy 16:36.Wordpress alatti Phpmyadmin amúgy, de Wordpress-ben is jó időzóna van beállítva (UTC+1), illetve Phpmyadmin is a pontos időt adja vissza a
SELECT NOW()lekérdezésre.Oké, nyilván tudnám korrigálni úgy, hogy hozzáadok egy órát, de tudni szeretném vajon hol és miért megy félre a dolog, miért vonja le azt az 1 órát.
A forrás adott, tehát nem megoldás, hogy kiveszem belőle a " +0100" részt.
Köszi előre is.
-
coco2
őstag
Még egy apróság. Ha a DocumentRoot nem úgy kezdődik, hogy "/var/www/", egyszerűen csak nem szolgálja ki az apache valamiért. Hogy valami régi dolog, vagy új, nem tudom, sokáig nem követtem a verziók nyavajáit. Szükség megoldásként beraktam egy soft linket a www mappa alá, és arra mutat a document root. Bele éppen nem halok, de ha egyszerűen orvosolható a jelenség, egy tippet megköszönnék. Megkímélne +1 soft link-re figyeléstől.
-
coco2
őstag
válasz
sztanozs
#20291
üzenetére
@sztanozs:
Köszönöm a figyelmeztetést. Egy spa / api szerver készül éppen, file hozzáféréseket nem tervezek paraméterbe rakni.
@nevemfel:
Köszönöm a tippet. Beállítottam normálisra az elérési jogokat, és most már működik, amit nem értettem. Illetve egy apróság még alant.
@supercow:
Elfogadom a gondolatot, és átszerkesztem a site-ot. Egyetlen nyitott kérdés maradt htaccess használatára, az pedig a bináris anyagok átlinkelése a stie-ról, ami kvázi sávszélesség támadása. Még nézem, hogy azt a rewrite rule-t berakhatom-e a virtual server beállítások közé, vagy annak viszont tényleg htaccess-be kell kerülnie. Ilyesmi:
RewriteEngine onRewriteCond %{HTTP_REFERER} !^$RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?mydomain.com [NC]RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]Más:
Egy index.php-ba ennyit raktam bele:
<?php var_dump(file_get_contents("index.php")); ?>Ha valami html állományt linkelek be, vagy bármi mást, arra működik, szépen képernyőre dobja a tartalmát. Viszont ha php állományt, arra üres stringet kapok vissza - furcsa mód a string korrekt hosszúságával, de akkor is üres string.
A szerveren egyébként be van állítva script cache ezekkel:
"opcache.enable=1""opcache.memory_consumption=128""opcache.interned_strings_buffer=8""opcache.max_accelerated_files=1000""opcache.use_cwd=1""opcache.validate_timestamps=1""opcache.revalidate_freq=2""opcache.revalidate_path=0""opcache.max_file_size=0"
Az ember azt hinné, a php file-ok nem kerülnek blokkolás alá vagy olyasmi. Pláne, hogy kívülről text editorral bele tudok nyúlni akármelyikbe.Van valami kézenfekvő magyarázat a jelenségre?
-
coco2
őstag
válasz
sztanozs
#20289
üzenetére
Csak hogy megnyugtassam magam, hirtelen rápróbáltam, hogy document root fölötti mappában létezett a "dead.letter" file, és hogy mit lép az apache-om a "www.mydomain.com/../dead.letter" -re. Visszaírta "www.mydomain.com/dead.letter" -re, pedig úgy emlékszem, nincs ilyen céllal rewrite rule-om. Ha működik is valami védelem, az alap beállítás lehet. Valós tud még lenni az a veszély a jelenkori világban?
-
nevemfel
senior tag
A laravel trükkjét viszont nem ismerem. Nem értem az utalást a public/ mappára. Valami gyakorlati rávilágítás jól jönne.
Egyszerűbb a document_root-ot egy public almappára állítani, a publikus fájlokat pedig abba rakni, mint magára a teljes projekt könyvtárszerkezetére megadni, hogy aztán egyenként kelljen beállítani htaccessel a hozzáférési jogokat bizonyos fájlokhoz és folderekhez.
-
coco2
őstag
válasz
supercow
#20284
üzenetére
Oké, a .htaccess per folder, ez benéztem, köszönöm a megoldást
A laravel trükkjét viszont nem ismerem. Nem értem az utalást a public/ mappára. Valami gyakorlati rávilágítás jól jönne.
Jelenleg ami van a virtual serverben, az "DocumentRoot /var/www/my-website". Oda terveztem berakni minden nyilvános cuccot egyben (összesen talán 30 file-ról beszélünk a kliens oldali .png grafikákkal együtt), és egy "/var/www/my-website/private" mappába a php libeket, meg a cron jobbal futtatott php cli-ket (talán 15 file fog oda kerülni összesen).
Milyen játékot lehetne játszani a mappákkal meg a document root-tal?
-
supercow
őstag
Nem lenne egyszerűbb a gyökérben bontani nyilvános és privát mappákra? Ahogy pl a Laravel csinálja Apache alatt, át kell állítani a DocumentRoot konfigot a public/ mappára. Hasonlót nem tudsz csinálni?
Ha mindenképp .htaccess kell, akkor a privát X mappában csinálsz egyet és abba beteszed eztOrder deny,AllowDeny from allVagy google “htaccess deny current directory” az apache verzióddal.
-
coco2
őstag
.htaccess példák között kotorászok, és nem találok példát mappa tiltásra
Viszonylag egyszerű site szerkezet, gyökér könyvtárban hagynám az összes nyilvános cuccot, és a gyökérben lévő X mappába pakolnám az összes többit (tipikusan php-ban require_once-al behúzott php libek kerülnének külön). Akinek van ilyesmire htaccess példája, esetleg megkérném rá, koppantsa be, vagy örülnék bármi netes blog url-nek olyan példával.
Köszönöm
-
sztanozs
veterán
válasz
don_peter
#20279
üzenetére
Inner join leszűkíti a találatokat azokra (és csak azokra) az elemekre, amelyek egyeznek - tehát ahol a topik_id és dátum páros az, amit a belső selectben kitúrtál. IUgazából a te esetedben mindhol lehetne inner join-t használni, hiszen a biztos kell lenni egyezésnek userekre és topikokra is.
Amúgy nincs abban a táblában egy ID mező (ami szigorúan emelkedő)? akkor talán egy kicsivel még egyszerűbb (és gyorsabb) volna, és szerintem belülre is rakható a Limit, az is csökkentené a terhelést:SELECT
t.id, t.title, fu.datum, u.nick
FROM
forum_uzenetek fu
INNER JOIN (
SELECT
MAX(id) AS id
FROM
forum_uzenetek
GROUP BY
topik_id
ORDER BY
id DESC
LIMIT 10) m USING (id)
INNER JOIN
topik t ON fu.topik_id = t.id
INNER JOIN
users u ON fu.user_id = u.id
ORDER BY
datum DESC -
don_peter
senior tag
válasz
sztanozs
#20277
üzenetére
Ez működik és jól listáz.
Kérdésem az, hogy ez nem e bonyolultabb mint a dupla csoportosításos megoldásom?
Illetve kérnék egy magyarázatot az inner join () részhez, hogy teljesen tiszta legyen számomra mit is csinál az a rész. Nem alkalmaztam még ezt a csatolást. Köszi előre is a türelmed. -
-
sztanozs
veterán
válasz
don_peter
#20274
üzenetére
Talán:
SELECT
t.id, t.title, fu.datum, u.nick
FROM
forum_uzenetek fu
INNER JOIN (
SELECT topik_id, MAX(datum) AS datum
FROM forum_uzenetek GROUP BY topik_id) max USING (topik_id, datum)
LEFT JOIN
topik t ON fu.topik_id = t.id
LEFT JOIN
users u ON fu.user_id = u.id
ORDER BY
datum DESC
LIMIT 10 -
nevemfel
senior tag
válasz
don_peter
#20265
üzenetére
Itt valami szerveroldali query optimalizáció kavarhat be. Az egyetlen különbség, amit látok, az annyi, hogy a második lekérdezésnél, a belső query-ben szerepel egy GROUP BY fu.id, aminek önmagában nem látom értelmét, hiszen a fu.id egyedi azonosító minden üzenetre (már ha jó a sejtésem a táblaszerkezetet illetően).
A külső lekérdezésnél a GROUP BY id-nál nincs t. előtag, ami, talán, jóég tudja persze, de akár többféleképpen is értelmezhető a mysql által.
-
don_peter
senior tag
-
don_peter
senior tag
"Az Önt kiszolgáló szerveren az éjszaka folyamán elvégeztük a kötelező mysql 5.6-ról 5.7-re való váltást, mivel a mysql 5.6 támogatása megszünt a cPanel hivatalosan minimum az 5.7-es verziót támogatja már csak."
Ezt a választ kaptam, hogy volt e valami kavarás a szervereken. -
sztanozs
veterán
válasz
don_peter
#20270
üzenetére
Esetleg, ha tényleg MariaDB (ver 10.2+)SELECT * FROM
(
SELECT
t.id,
t.title,
fu.datum,
u.nick
RANK() OVER (PARTITION BY topik_id ORDER BY datum DESC) rank
FROM forum_uzenetek fu
LEFT JOIN topik t ON fu.topik_id = t.id
LEFT JOIN users u ON fu.user_id = u.id) temp
WHERE rank = 1
ORDER BY datum DESC
LIMIT 10Mostz látom mysql 5.7 -ott még nincs window function
-
don_peter
senior tag
válasz
sztanozs
#20267
üzenetére
Sajnos az összeállított kódod hibás listát eredményez, de majd ha lesz kicsi időm átnézem, mert talán irányvonalnak nem rossz.ui: jelzem, hogy 2021-es dátummal is születtek bejegyzések, a helyes lista az előző bejegyzéseim egyikében szerepel kóddal és képpel illusztrálva..
Második kódod ugyan úgy hibás, első dátum 2019-03-16.
-
sztanozs
veterán
válasz
don_peter
#20268
üzenetére
szerintem az volt a gond, hogy a fu és a f táblában is van datum mező. Eddig a fu.datum-ot vette fel, de szerintem most az f-datum-ot (de mivel nem látoma tábláidat így csak találgatok). Egyébkéntsikerült kipróbáűlni az átlalam javasoltat? ha belülre teszed a limitet (és biztos ami biztos kétszer rakod sorrendbe akkor sokkal olcsóbb a query):
SELECT
t.id,
t.title,
fu.datum,
u.nick
FROM
( SELECT
*
FROM
forum_uzenetek
GROUP BY
topik_id
HAVING
datum = max(datum)
ORDER BY
datum DESC
LIMIT 10) fu
LEFT JOIN topik t ON
fu.topik_id = t.id
LEFT JOIN users u ON
u.id = fu.user_id
ORDER BY
fu.datum DESC -
-
don_peter
senior tag
Ezen a képen a régi állapot látható, és sajnos nem jól listáz, nem veszi figyelembe a bejegyzések dátumát. Pár nappal a frissítés előtt még jól listázott.
Ez pedig a módosított állapot, amikor már jól listáz.
Itt a szubselect-be egy plusz csoportosítást kellett elhelyeznem, így helyre állt a régi és jó listázási állapot.
Kérdés az, hogy lehet e ezt jobban és szebben megoldani? -
don_peter
senior tag
Hölgyek, Urak!
Az elmúlt napokban volt a szolgáltatómnál SQL és PHP verzió frissítés és emiatt néhány SQL lekérdezésem hibássá vált. Kérném a segítségeteket, hogy rendbe tudjam rakni a hibát.
A hibás kód az új verzióban:SELECT
*
FROM
(
SELECT
t.id,
t.title,
fu.datum,
u.nick
FROM
forum_uzenetek fu
LEFT JOIN topik t ON
fu.topik_id = t.id
LEFT JOIN users u ON
u.id = fu.user_id
ORDER BY
fu.datum
DESC
) AS a
GROUP BY
id
ORDER BY
datum
DESC LIMIT 10
Gondolom a táblák és mezők elnevezése érthető, t = topik, fu = fórum üzenetek és u = felhasználók.
Ez a kód a régi verzióban jól működött vagy is ki listázta a topikokat a topikba írt utolsó bejegyzésének dátumánál fogva csökkenő sorba rendezve. A csoportosítást pedig azért használtam, hogy egy topik csak egyszer szerepeljen a listában.Tehát ami kellene, hogy az utolsó bejegyzések dátuma alapján listázza ki a topikokat, fontos, hogy topik csak egyszer szerepelhet a listába.
Köszi előre is a segítséget. -
coco2
őstag
Sziasztok!
Egy php program összesen ennyi:
<?php
$xx= file_get_contents("https://wowcircle.net/en.html");
echo $xx;
?>Ha lefuttatom cli-vel, a válasz rá:
D:\>C:\wamp64\bin\php\php7.4.9\php.exe exec.txt
Warning: file_get_contents(https://wowcircle.net/en.html): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found
in D:\exec.txt on line 2
D:\>Ha beírom a lapot böngészőbe, természetesen letölti. Ebben a tegyük működésképtelenné a webscrapereket játékban én még új vagyok. Hol van a kutyus elföldelve?
-
Agostino
addikt
sziasztok
hogyan kellene ezt a kérdést kezelnem szerintetek? adott egy loop, amiben szerepel egy mysql query. minden évhez hozzá van rendelve egy adatbázis mentés. ha a felhasználó azt mondja, őt a 2018 és a 2019-es mondjuk eladott almák száma érdekli, akkor 2018ben a loop a 2018-as adatbázishoz nyúl, 2019-ben a 2019-hez majd soronként kiírja a darabszámot.
viszont azt mondja a főnök, hogy rendben, de 2018ban az almákat eltérően számoltuk, és 2019-ben is máshogyan. tehát a loopnak figyelnie kellene az éves adatbázis váltást és a query váltást is. a kis kódom nagyon röviden valahogyan így néz ki:
if (loop éve 2018 majd 2019) {ha dátum ez, használd ezt az adatbázist2018.adatbazisa.query majd 2019.adatbazisa.queryecho eredmény } -
#68216320
törölt tag
Sziasztok.
Tudnátok ajánlani olyan File listázó/letöltő programot (vagy csak osztályt) amit könnyen üzembe lehetne helyezni? Fontos lenne, hogy minimális vagy leginkább semmi JS és CSS legyen benne, mivel olyan eszközök számára a készülne, amiknél ez gondot okoz. ('80-'90)
Alapvetően majdnem megfelelő a normál apache/nginx könyvtárlista.A következő kritériumoknak kellene megfelenie:
- tetszőleges mélységű könyvtárlista (dir elöl, fájlok utána sorrend)
- ne direkt link legyen a fájlra, hanem mondjuk "download.php?dir=104&file=valami.ext" vagy valami ilyesmi
- adott fájl letöltésének számlálása (nem JS-el, mondjuk a fentebb említett download.php segítségével)
- könyvtárakat automatikusan térképezze fel, mivel nem web felületen lenne tartalom feltöltve
- több fájl/könyvtár kiválasztása esetén azokat 1db zip-ben töltse leEnnyi lenne.
Ismeretek esetleg ilyen kész rendszert? -
#20243
instantwater
addikt
Mike
#20242
-
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? -
#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
-
#20240
instantwater
addikt
coco2
#20239
-
#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ó.
-
#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)
-
#20234
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ó?
-
#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.
-
#20232
instantwater
addikt
coco2
#20231
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.
-
#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
-
#20230
instantwater
addikt
coco2
#20229
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.
-
#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?
-
#20228
instantwater
addikt
coco2
#20227
-
#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.
-
#20226
instantwater
addikt
coco2
#20225
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. -
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.
-
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
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.)
-
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
-
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.
-
#20215
instantwater
addikt
disy68
#20211
-
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.
-
coco2
őstag
-
#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. -
#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. -
#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
-
#20209
instantwater
addikt
coco2
#20208
-
#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é.
-
#20207
instantwater
addikt
disy68
#20205
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. -
#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
-
#20204
instantwater
addikt
coco2
#20203
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.
-
#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.
-
#20202
instantwater
addikt
Gergello
#20201
-
#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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- HP Elitebook Folio 9470M laptop (14/i7-G3/6GB/256SSD)
- LG 45GS95QX-B 45" ÍVELT OLED MLA WQHD 240HZ 0.03 MS GAMING MONITOR
- HP Zbook 15 laptop (15,6FHD/I7-G4MQ/16GB/128SSD/Nvidia2GB)
- Latitude 7450 14" FHD+ IPS Ultra 7 165H 32GB 1TB NVMe IR kam gar
- LG 45GR95QE-B Ívelt OLED 2K WQHD 240Hz, 0.03ms, NVIDIA G-Sync ,FreeSync Premium ,HDMI 2.1
- DUPLA XEON GOLD 6134!!! HP Z8 G4 LEGNAGYOBB WORKSTATION 64GB 2x8 mag 2x16 szál gamer, szerver, munka
- BESZÁMÍTÁS! Gigabyte A620M R5 7600 32GB DDR5 512GB SSD RTX 4070 12GB ZALMAN S2 TG EVGA 650W
- LG 27GR93U-B - 27" IPS - UHD 4K - 144Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDR 400
- Bomba ár! HP ProBook 430 G3 - i5-6GEN I 8GB I 256SSD I HDMI I 13,3" HD I Cam I W10 I Garancia!
- iKing.Hu - Motorola Edge 50 Ultra - Nordic Wood - Használt, karcmentes
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged