PHP fájlok védelme .htaccess-szel

Adott az alábbi felállás:

#apache rewriteunk a következő:

/minta => /modules/mod_minta.php
/minta/1 => /modules/mod_minta.php?q=1

## ki hogy vitelezi ki, teljesen lényegtelen, nézzen ki pl így:
RewriteRule ^minta(/.*)?$ /modules/mod_minta.php?q=$1 [QSA,L]

## $_GET['q'] feldolgozása phpban történik

Tehát a http://example.com/minta url hívásakor valójában a http://example.com/modules/mod_minta.php hívódik meg és hasonlóan a http://example.com/minta/1 esetén a http://example.com/modules/mod_minta.php?q=1

Tiltsuk le a következő linket: http://example.com/modules/mod_minta.php?q=1. Tehát a címsorba közvetlenül írva adjon valami hibát, de semmiképpen se futtassa le a mod_minta.php-t.

Több lehetőség van:

A modul(ok) elejére beírkáljuk:

 if(eregi('mod_minta.php', $_SERVER['REQUEST_URI'])) {
	header('HTTP/1.0 403 Forbidden');
	exit;
}

Egyszerű, és ronda megoldás. Minden mod_minta.php meghíváskor lefut, az esetek 99.9999%-ában feleslegesen.

Sokkal szebb megoldás a következő kettő…

  • Adjunk rá 404-es hibát:
    RewriteCond %{THE_REQUEST}      ^(GET|HEAD|POST)\ /modules/mod_minta\.php
    ## a mod_404.php kezeli a 404-et, ki hitte volna, ezt korábban már rewriteoltuk
    RewriteCond %{REQUEST_URI}  !^/modules/mod_404\.php$
    RewriteRule $ /404 [L]
    

    Ebben az esetben csak a mod_404.php-t tudja elérni közvetlenül, más nem. Ezt az egyet engedni kell, mert különben végtelen rekurzióba fut az apache. Ilyenkor a címsor nem változik, nincs redirect.

  • Dobjuk rá a 404-es oldalra
            RewriteCond %{THE_REQUEST}      ^(GET|HEAD|POST)\ /modules/mod_minta\.php
            RewriteRule $ /404 [R=301,L]
    

    Itt redirect lesz, ebben az esetben semmilyen file nem érhető el közvetlenül.

A kiprobált környezetben minden url rewriteolva van, tehát közvetlenül egy php file sincs meghívva. Ebben az esetben a két megoldás valamelyikét javasolt a rule-ok legvégére tenni, mert csak akkor jut el idáig a feldolgozás, ha korábban egy szabály sem illeszkedett. Ha ez sem illeszkedik akkor sima 404 a végeredmény.
A 404 megfejtése nagyon egyszerű:

ErrorDocument 404 /404
######
######
######
RewriteRule ^404$  /modules/mod_404.php [QSA,L]

Kiegészítve a RewriteCond-ot:

RewriteCond %{THE_REQUEST}      ^(GET|HEAD|POST)\ /modules/mod_.+\.php

Tehát az összes mod_-dal kezdődő php file közvetlen elérésének a tiltása ilyen. :)

Hány hétből áll egy év?

Egy kérdéses évben lelendő hetek számát megkapjuk, ha az adott évet áthajtjuk a következő függvényen:

function getweeksnumber($year){
    return max(date('W', mktime(0,0,0,12,25,$year)), date('W', mktime(0,0,0,12,31,$year)));
}

Ötletes, nemde?

PHP: session_id() nem működik

Egy napja fennálló probléma, megoldást nem találtam még rá, segítsetek. A következő van:
A session_id(’1234566′); beállítja a sid-et a megadottra, ezután session_start-tal ergo “felkaphatunk” egy már meglévő sessiont. Lássunk rá egy tesztkódot:

      if (isset($_GET['destroy'])) { ## csak a játszásiból
            session_start();
            setcookie(session_name(), '', time()-42000, '/');
            session_destroy();
            exit;
      }
      if (isset($_GET['setsid'])) {
            session_id($_GET['setsid']);
            session_start();
            echo (session_id()==$_GET['setsid'] ? 'ugyanaz':'nem ugyanaz').'';
            if (!empty($_SESSION['test'])) {
                echo $_SESSION['test'];
            } else {
                echo 'nem mukodik.';
            }
            exit;
      }
      session_start();
      $_SESSION['test'] = 'test';
      echo 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'].'?setsid='.session_id().'';
      echo 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF'].'?destroy';

Tehát indítok egy sessiont, test változóba test érték, majd kiíratom a linket, amit egy másik böngészőbe betéve “test” feliratnak kéne megjelenni. Ehelyett az jelenik meg, hogy ‘nem mukodik.’ A session id-t megkapja, az lesz, aminek kell lenni, de a $_SESSION mégis üres. A fenti script működik PHP 5.2.6 alatt (átkapja a sessiont a másik böngésző), de 5.2.10 alatt nem(üres a $_SESSION). A php.ini elvben egyezik a két verzióban.

Ötlet?

Különbségek a Windows XP és a Linux között

edfa

Internet Explorer - Lightbox - A művelet megszakadt

A Micro$oftot sem a böngészője miatt szeretjük (de Surface az van), hanem azért, mert kihívásokat állít elénk, hogy kell egy szakosan megírt javascript forrást lebutítani, hogy azt az IE is megértse. Történet a következő:
Az “új” Lightbox 2.04 ( a szinte teljesen újraírt forrásával) már nem a

function initLightbox() { myLightbox = new Lightbox(); }
Event.observe(window, 'load', initLightbox, false);

megoldást használja, hanem a szebb

document.observe('dom:loaded', function () { new Lightbox(); });

Tapasztalatunk szerint:
Ez így magában működik, de ha például saját javascript kódokat is akarunk betöltéskor futtatni akkor két lehetőség van:

document.observe('dom:loaded', function () {
//sajátkód
});
//vagy
Event.observe(window, 'load', function(){
//sajátkód
}, false);

Ha változatlanul hagyjuk a lightboxot, és dom:loaded-et vegyítjük a Event.observe-vel, akkor kapjuk “A művelet megszakadt” üzenetet. Kipróbáltuk, azt tapasztaltuk, hogy két dom:loaded-et sem kedvel az IE. Köszönjük. Az maradt a megfejtés, hogy a lightbox inicializálást át kell írni a “régire”:

online casinoEvent.observe(window,'load',function(){ new Lightbox(); },false);
//document.observe('dom:loaded', function () { new Lightbox(); });
//vagy, kiremeljük a lightboxban az initet, és a saját kodunkban hívjuk meg.
Event.observe(window,'load',function(){
new Lightbox();
//saját kód
},false);

Múkodj!

Készíts backup-ot

Kilencven valahányban, mikor elkezdtünk iskolai szinten is ismerkedni a számítógéppel, akkor tanultunk meg egy nagyon fontos dolgot, ami paranoiává vált az idők folyamán. Kaptunk egy programot papíron, és azt kellett begépelni, majd bizonyos módosításokat elvégezni rajta. Óra végén pedig osztályozás. Másfél ujjas gépelésről volt szó, sok időt pazarolva a billentyűk keresésére… Dupla óra, legvége előtt 10 perccel a tanár odament a főkapcsolóhoz, és hanyag eleganciával lekapcsolta. Majd jött a naplóval, és szépen sorba véste be az egyeseket, mondván, semmit nem csináltunk az órán. Természetesen akkor mindenhova kívántuk, hogy lehet ekkora gyopár, hogy tönkreteszi a munkánkat. Következő órán pótlás, természetesen megint eljátszotta ezt, ismét egyes, bukásra állunk informatikából. Legközelebb, amikor a kapcsoló irányába ment, már mentettünk, ekkor tette szóvá először - ha jól emlékszem -, gyerekek, mentsetek. Többet nem volt órai adatvesztés. Megtanultunk menteni. Akkoriban egy 1.44-es floppyn elfért több havi “munkád”, amit hobbiból kódoltál otthon, vagy órák után a suliban. Aztán bejöttek a cd írók, mobil rackek, könnyebbé és biztosabbá vált az archiválás. De mentettük minden munkánkat!

Mindegy hogy mentesz, ments úgy, ahogy neked jó, egy a lényeg, mindig találd meg a szükséges adatot, amikor arra szükség van, és a lehető leggyorsabban tudd visszaállítani. Ne ezt kérdezd, hogy mennyibe kerül a biztonsági mentés kialakítása, azt kérdezd: Mennyibe kerül, ha nem alakítod ki!

BÚÉK 2009

Kívánunk mindenkinek

  • szerverfagyás mentes
  • alacsony bounce rate-es
  • slow query mentes
  • sok látogatós
  • hackmentes
  • sikerekben gazdag

újévet!

A lottó ötöst meg magunknak!

Boldog Új Évet Kívánunk!

Mobil internet kell, de nincs

Nem szeretek ilyenekről írni, megteszik ezt mások helyettem, jobban, de egyszerűen komikus, hogy 2008-ban ilyen van. Arra már rájöttem tudatos fogyasztóként, hogy általában az interneten és egyéb máshol forgalmazott termékek és szolgáltatások a nagyközönségnek vannak kitalálva, aki mást akar, az meg van fogva, turkálhat, rohangálhat, de az a tapasztalat, hogy benézte. Vagy ha van is kínálatban, épp elfogyott. Én nem akarok birkaszerűen vásárolni, fogyasztani! A történet a következő: Folytatás >>

Programozzunk

Fejlesztés közben előfordulnak vicces kódsorok, megjegyzések, vagy mert sietünk, vagy mert direkt, vagy mert tök véletlenül egyszerű figyelmetlenségből. Írjatok pár eszement sort amit elkövettetek, és már-már szégyellitek bevallani a nagyközönségnek, hogy Ti ilyent is tudtok. Kezdem Én:
Folytatás >>

E-mail ellenőrzés php-ben

Korábban beszéltünk az adatvalidálásról, de sosem lehet elég a jóból. Még mindig akad olyan felhasználó, aki képes kijátszani az emberi értelem határait, és elköveti azt a galádságot, hogy helytelen e-mail címet ír be. Különösképp arra az esetre gondolunk, mikor (kimondva) halvány fingja nincs az e-mail címéről, stbstb. fremail.com, hotmail.hu, citrommail.com és sorolhatnánk. Folytatás >>

Következő »