autorizaacija

[рпр]

lai buutu daudzmaz sekjuuri esmu uztaisiijis taa, ka kuukijaa saglabaajaas kripteets username un passwd implodeets ar : , un pie katras lapas paarlaades tiek veikta paarbaude vai username un passwd ir pareizi.

 

shajaa gadiijumaa tas vareetu butu sameeraa droshi,bet kaa buus ja lietotaaju skaits buus ljoti daudz, tad manupraat shii katras reizes autorizaacija vareetu ievilkties, jo manupraat mysql tabulai nekaadus indeksus nevar uzlitk ja tiek ieziimeeti konkateneeti laucinji.

 

kaadi ierosinaajumi, lai tas buutu gana aatri un droshi? datiem noteikti ir jaaglabaajaas mysql tabulaa taa ka visaadi mod_auth shoreiz neder.

[Braiens]

Ir tada lieta kā:

<?
$cookie = $_COOKIE['pass'];
if (!isset($cookie)) {
echo '
<form method="POST" action="?id=in"><input type="password" name="pass"
size="20"><br>
<input type="submit" value="Submit" name="in"></form>
';
}
if($_GET['id']=="in") {
if($_POST['pass']=="PASS") {
setcookie("pass", $_POST['pass'], time()+3600);
echo '<meta http-equiv="refresh" content="0; url=index.php">';
} else {
echo "Ta vairs nedari";

$filename = 'ip.txt';
$ip = getenv("remote_addr");
$somecontent = $ip." ".$_POST['pass']."\n\r";

if (is_writable($filename)) {

  if (!$handle = fopen($filename, 'a')) {

        exit;
  }

  if (!fwrite($handle, $somecontent)) {

      exit;
  }

  fclose($handle);

} else { } } }

if(isset($cookie)) {
//lapas kods
) 
?>

[Venom]

kūkiji ... nu nevajadzētu būt pārāk drošiem, it īpaši ja tajos glabājas paša parole

labāk izmanto $_SESSION un vai nu saglabā tajā kaut ko tādu unikālu, ar kuru čeko, vai ūzeris bija pareizos datus ievadījis, vai nu ja tomēr gribi katru erizi čekot ar MySQL, mēģini vismaz tos kquerijus nokešot (sk. SELECT manuālī)

 

es taisītu ko līdzīgu:

ja iesūtīti dati ar paroli un ūsernamu

pārbaudu ar mysql, vai tāds ūseris iraid,

ja iraid, lieku iekš session kaut kādu $_SESSION[session_id()]=md5(session_id());

vēlāk čekoju, if (isset($_SESSION[session_id()] && $_SESSION[session_id()]==md5(session_id())) tad ielogots

plusi tādi, kā:

1) nekur netiek saglabāta parole (ok, lietotāja vārdu var saglabāt)

2) sessijām grūtāk piekļūt nekā kūkijeim (parasti - jāpiekļūst fiziski serveram)

3) pat ja izķer sessijas datus

a) no tiem neko nesapratīs

B) ne uzreiz sapratīs, pēc kāda algoritma ir nokriptēta vērtība un kāda vērtība (md5 vietā var izmantot crypt() f-ju ar mainīgu salt)

c) pat ja pārķer datus, tie nebūs derīgi vēl vienai konekcijai /ja vien nekonektējas no tā paša browsersofta ar papildus parametriem/ - jo katru reizi mainīsies session_id()

[Robis]

Vispaar man ir arii dazhi jautaajumi attieciibaa uz autorizaaciju!

1) kaads vareetu buut visdroshaakais autorizaacijas panjeemiens pret neautorizeetu pieeju? (varbuut jaaizmanto JavaScript promt logs, kad izlec uzreiz, kad lapa ielaadeejas un tikai peec pareizas user + password ierakstiishanas lapa redirekteejas uz izmantojamo?

2) kaa droshi aizsargaat tos php failus, kuriem nepiecieshama autorizeeta pieeja tikai?

 

Vienuvaardu sakot - vai kaads zin visdroshaakos panjeemienus, teiksim admin pieejas aizsardziibai? (iznjemot paaraak advanceeto SSL)

[Venom]

Vispaar man ir arii dazhi jautaajumi attieciibaa uz autorizaaciju!

1) kaads vareetu buut visdroshaakais autorizaacijas panjeemiens pret neautorizeetu pieeju? (varbuut jaaizmanto JavaScript promt logs, kad izlec uzreiz, kad lapa ielaadeejas un tikai peec pareizas user + password ierakstiishanas lapa redirekteejas uz izmantojamo?

2) kaa droshi aizsargaat tos php failus, kuriem nepiecieshama autorizeeta pieeja tikai?

 

Vienuvaardu sakot - vai kaads zin visdroshaakos panjeemienus, teiksim admin pieejas aizsardziibai? (iznjemot paaraak advanceeto SSL)

1) droši vien esi redzējis izlecošus logus, bet tie nav javasript, bet gan iekšējo serveru autorizācijas protokolu (Basic/NTLM/LDAP u.c.) izsauktie logi, šajā gadījumā nonākam pie

2) kas ir SIngle-Sign-On (vienreizējās autorizācijas) paņēmiens

 

Globāli tam ir 3 pieejas

1) pieejas liegšana tieši no skripta, jebšu tu uztaiši kādu pārbaudes failu check.php, kuru require_once(); katra "aizsargājamā" faila pašā sākumā - check.php pie nepareizo datu ievadīšanas vai nu taisa exit;, vai nu iz-echo kaut kādu paziņojumu un exit;, vai nu taisa redirektu utml.

2) pieejas liegšana no servera puses - izmantotjo (Apache gadījumā) httpd.conf un .htaccess failus var globāli uzlikt kaut kādus ierobežojumus - pēc IP, pēc ūsernāmiem (require_valid_user), tad izlec šāds te logs un prasa ievadīt paroli, arī ja tu neizsauc pa tiešo *.php, bet var liegt pieeju arī direktorijām un failiem. Tad neielogotam ūserim serveris pat nesūtīs tev šo failu informāciju.

3) abu pieeju maisījums, piem. atļaut pieeju tikai no iekšējā LAN IP-adresēm, bet arī pajautājot kādu paroli.

[рпр]

par to selektu keshoshanu laba doma,vieniigi pagaidaam veel par sesijsijaam man ir tumsha bilde.varbutu var kaadu manuaali ar piemeeriem par sho teemu iemest (sesijaam),tad dienas laikaa varbuut veel kaads jautaajums paviidees.

[рпр]

interesanti, ka tagad postojot datus man paraada apacha error failaa, ka [notice] child pid 13512 exit signal Segmentation fault (11) un ar sesijam nekas nenotiek, kautgan sesijas kuukijs tiek pieshkjirts un tmp direktorija sessijas faili paraadaas.

[рпр]

interesanti 2.

 

ja session_start izmanto funkcijaa un shajaa funkcijaa globaalo mainiigo uzliek $_SESSION, tad saak interesanti uzvesties webservers.