StarBlog

Előfordulhat fejlesztés közben, hogy egy-egy nagyobb időegységet szeretnénk tudni másodpercben, csináltam egy táblázatot, hogy ne kelljen mindig számolgatni:

Átirányítás.  Na ez pont egy olyan téma, amit jó sok féleképpen meg lehet oldani. Épp ma volt szükségem rá, mivel egy blogszolgáltatónál lévő blogot kellett redirectelni.

Először PHP-vel probálkoztam, ami a legegyértelműbb:

1
2

header('HTTP/1.1 301 Moved Permanently');
header('Location: http://blog.starweb.hu/');

Na mivel ez kapásból nem sikerült, mivel a sablonban ez nem futott le, így jött a HTML:

1

<meta http-equiv="refresh" content="0;URL=http://blog.starweb.hu" />

Itt már majdnem jó volt, csak épp a 0 másodperc is valami, ami épp elég volt ahhoz, hogy a régi lap is feltűnjön a színen. No ezért lett a legjobb megoldás a JavaScript.

1
2
3
4
5

<script type="text/javascript">
<!--
   window.location = "http://blog.starweb.hu/"
//-->
</script>

A napokban készítek épp egy igen egyszerű oldalt, ahol nem volt szükség semmilyen komolyabb keretrendszerre, így a következő megoldással készítettem el a navigációt, tehát a main.php tartalma az alábbi lett:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

$page = $_GET['page'];
 
include('header.php');
 
switch($page) {
   case "szolgaltatasaink":
   $content = "services.php";
   break;
   case "referenciak":
   $content = "references.php";
   break;
   case "kapcsolat":
   $content = "contact.php";
   break;
   default:
   $content = "introduction.php";
   break;
}
 
include($content);
 
include('header.php');

Tehát a $_GET['page'] változóval meghatározott oldalt egy switch segítségével azonosítjuk be, majd a folyamat végén includoljuk. Ez a megoldás kitűnően alkalmazható kis oldalaknál.
Ez így még nem igazán megfelelő nekünk, mivel minden oldal URL-je a következőképpen fog kinézni:

http://domain.hu/main.php?page=kapcsolat

Hogy ezt elkerüljük az Apache mod_rewrite modulját használjuk. A kétrehozott .htaccess fájl tartalma:

1
2
3

Options +FollowSymLinks
RewriteEngine On
RewriteRule (.*).html main.php?page=$1

Ezt követően linkelhetjük már így az oldalainkat:

http://domain.hu/kapcsolat.html

Tehát alig pár sor kóddal sikerült összeállítani egy jól áttekinthető forrást, illetve egy keresők könnyen követhető linkstruktúrát.

A phpinfo függvény a PHP telepítési beállításiról ad információkat. Érdemes letiltani a PHP konfigurációs beállításaiban (melyet a php.ini fájlban találunk meg), mert az általunk írt oldal felhasználóit nem érintik ezek az adatok, a hackereknek pedig nem akarunk segíteni.

1
2
3

<?php
   phpinfo();
?>

És a kikapcsolása a php.ini-ben:

1

disable_functions = phpinfo

Bevezetés

A Világháló az ügyfél-kiszolgáló elven működő rendszerek különleges fajtája. Az ügyfél-kiszolgáló rendszerű hálózatokban a bonyolult, időigényes számításokat nagy teljesítményű (és költséges) számítógépek, úgynevezett kiszolgálók végzik. Ezek a gépek kisebb teljesítményű, úgynevezett ügyfeleket “szolgálnak ki”.

Ennek alapján kétféle szemléletről beszélhetünk:

„sovány ügyfél”: a legtöbb alkalmazás a kiszolgálón fut, de az ügyfelek is képesek kisebb számítási feladatokat elvégezni és helyben adatokat tárolni, míg a munka dandárját a kiszolgáló hajtja végre.

„kövér ügyfél”: minél több feladatot hárítunk az ügyfélre, annál gyorsabb lehet a végrehajtás a központi kiszolgálón. A számítási teher jobban elosztható, ezért a hálózat mindenki számára felgyorsul.

Ellentétes célok:

Biztonság és stabilitás: A stabilitás igénye gyakran arra készteti a fejlesztőket, hogy több kódot írjanak (például hibakezelő eljárásokat), a több kód azonban több hibalehetőséget is jelent.

Sebesség: minél több kódot hajtatunk végre az ügyféllel, annál gyorsabban futhat a kiszolgáló, de minél több kód fut az ügyfélen, annál nagyobb veszélybe kerül a biztonság, hiszen a felhasználó hozzáférhet az ügyfélen végrehajtott kódhoz.

Használhatóság: A felhasználót annyi információval látjuk el, amennyivel csak lehet, hogy a rendszert minél könnyebben használhassa. A könnyű használat azonban gyakran könnyű feltörhetőséget jelent, különösen, ha a hibaüzenetek a támadót segítő információkat fednek fel.

Az ügyfél-kiszolgáló hálózatoknak három lényeges elemük van:

a. kiszolgáló számítógép

b. webügyfél:

Ezt érdemes kicsit tüzetesebben is megnéznünk. Olyan webalkalmazásokat kell írnunk, amelyet a felhasználók kedvelnek, de az ellenség számára nehezen támadható célpontok. Ez alapján előjön pár fontos dolog, amire figyelnünk kell:

• Egy rosszindulatú felhasználó minden adathoz hozzányúlhat, amit a webügyfélen tárolunk. Minden érzékeny információ, megvalósítási részlet és így tovább, ami áthalad az ügyfélen, felfedhető, attól függetlenül, hogy milyen erőfeszítéseket teszünk a védelmére. Emellett az ügyfélen elhelyezett bármilyen azonosítási kód megkerülhető. A tanulság: ne végezzünk fontos számításokat és hitelesítést az ügyfeleken anélkül, hogy az adatot a kiszolgálón
  ne ellenőriznénk.
• A webügyfél felől érkező hálózati forgalmat teljes egészében hitelesíteni kell, és megbízhatatlanként kell kezelni. Az ügyféloldali webes interakciók nagy része egy webböngészőn keresztül történik, de erre nincs garancia. A tanulság: az ügyfélről érkező hálózati forgalmat teljes egészében ellenőrizni kell.
• A felhasználó minden ügyféloldali forráskódhoz hozzáférhet. Egy rosszindulatú felhasználó minden ügyféloldali kódot és adatot (HTML, Java, Flash stb.) megtekinthet és
  megváltoztathat. A tanulság: A forrásban nem tárolhatók titkok, és minden, amit a forrásban elhelyezünk módosítható.
• Az ügyfél képes arra, hogy részleteket derítsen ki a kiszolgáló oldali megvalósításról.
  A szabványos kiszolgáló oldali hibaüzenetek árulkodóak lehetnek. Kitalálható belőlük például a könyvtárszerkezet és a fájlok helye vagy a használt adatbázis-változat.

c. hálózat

• A Weben áthaladó adatok elfoghatók és megpiszkálhatók, ha sima szövegként továbbítjuk őket. A HTTPS protokoll a HTTP biztonságos átviteli formája, amely automatikusan titkosítja a webes kapcsolaton áthaladó forgalmat, de nem szabad elfelejtenünk, hogy a HTTPS munkamenet bemenetét jelentő adatok az ügyfélen születnek, tehát már a titkosítás előtt hozzájuk nyúlhatnak. A titkosítás nem nyújt valódi védelmet, csak azt akadályozza meg, hogy az adatokhoz átvitel közben nyúljanak hozzá, vagy hogy ekkor fogják el őket.

További gond, hogy a webfejlesztést rendkívül rövid fejlesztési ciklusok jellemzik, vagyis kevesebb idő jut felülvizsgálatra, tesztelésre, minőségellenőrzésre. A webfejlesztés emellett összetevő alapú, vagyis a fejlesztők már létező összetevők összeragasztásával és testre szabásával építik fel az alkalmazásokat. Ez azt jelenti, hogy egy webalkalmazás anélkül fejleszthető, hogy valóban részleteiben értenénk a megvalósítás elvét.

Említésre méltó még, hogy a weben a felhasználók névtelenek, és szinte minden álcázható vagy hamisítható, ezért az azonosítás igen nehéz. A web állapot nélküli, ezért ha valamit menteni akarunk egy webes munkamenetből, azt a köztes időben máshol kell tárolnunk. Az állapotfüggő tranzakciók kezelése tette szükségessé az olyan mesterséges mechanizmusok bevezetését, mint a sütik és rejtett mezők használata.