Jump to content
php.lv forumi

ezis

Reģistrētie lietotāji
  • Posts

    398
  • Joined

  • Last visited

Posts posted by ezis

  1. rATRIJ, es gan gribētu tev oponēt. Ja izmanto 4th generation MVC tipu - NNMVC - Neural Network Model View Controler, tad, principā, viņš pārspēj visus savus citu subkategoriju paternus, jo būtībā nav vairs vajadzīgs rakstīt nevienu koda rindiņu, tāpēc, ka web aplikācijas kods ģenerējas uz tā sauktā UF (user feedback) principa. Izvietojot NNMVC mākonī, vispār vari aizmirst par viņu, jo viņš pats skeilojās.

    Mūsu kompānija jau labu laiku šo izmanto, tas mums ļāva par 80% samazināt darbinieku skaitu, atlaižot visus programmētājus un klientu menidžerus. Palika tikai es - direktors, 3 sekretāres, grāmatvedis un 5 apsargi. Principā domāju, ka par ietaupītajiem līdzekļiem vajag noalgot vēl kādas 5-7 sekretāres.

     

    P.S. Starp citu tāpēc F3llony ir tik nikns uz MVC, jo tas aizstāja viņa agrāko darbu (viņš bija viens no tiem, kuru atlaidu). Tagad viņš mocās ar saviem SubCon un LDOLC un 4 stundas dienā nodarbojas ar meditāciju, lai pats sev pārliecinātu, ka tie ir labāki par MVC.

    omg! :OOOOOOO /me šokā

  2. Šoreiz es pat necentos troļļot. MVC savai popularitātei jāpateicas tikai popkultūras freimworkiem un populārajiem CMS kur jamais tiek izmantots. Bet ir 101 cita arhitektūra, kas pat labāk veic savus pienākumus, piemēram SupCon, DCI un vel vesela kaudze arhitektūru lai gan es pieturos pie "sava stila" jeb mans PHP pārsvarā ir SOOP kontroliera modelis ar šādu pašu loģisko plūsmu, bez atsevišķiem kontrolieriem un izmantojot sublevel api kā arī statiskos punktus, kā arī, tas ko es dēvēju par LDOLC jeb Loghic Dynamic Object Loader and Controller. Basicly tas ir viens master kontrolieris kas pēc loģikas un arhitektūras nepieciešamības izsauc subdimensionālas klases, kas atkal rīkojas tieši šā pat. Daži no maniem "mācekļiem" un tiem, kas iestaigā skype pēc padoma gan jau ir sastapušies ar šo loģiku.

     

    :*

    Man kā nejēgai varbūt vari parādīt kādu savu piemēru? :? Un varbūt pastāstīt, kāpēc tā būtu labāk nekā savādāk?

  3. Switch nesmuks, masīvi FTW!

     

    <?
    $mapping = array(
    "profile",
    "users",
    "random_shit",
    "default",
    );
    
    $cmd = isset($_GET['cmd']) && in_array($cmd, $mapping) ? $_GET['cmd'] : "default";
    
    include("files/$cmd.php");
    
    

    Arī var, bet ja es gribu ielikt random_shit vietā funkciju kādu nevis php.php? :D Netak, ir pa tēmu variants, tikai piesienos :D jo aiz "default" ir smuks komats! :D

  4. lietotājam ir cepums ar sesijas id.

     

    Kad lietotājs ienāk lapā, viņš padod serverim cepumu. Serveris paskatās, kas tur par id ir cepumā un attiecīgi izmanto to sesiju, kas atbilst šim cepumam. Serveris nekādīgi nepārbauda, vai lietotājam patiešām pieder šī sesija.

     

    Tāpēc, to tu vari darīt pats, ieliekot sesijā arī mainīgo, kas identificē īsto lietotāju, teiksim ip, vai useragent, vai abus kopā. Un, ja šis nesakrīt, visdrīzāk kāds ir nozadzis kādam citam sesijas identifikatoru un mēģina par viņi uzdoties :)

     

     

    Vēl viens drošības risks ir XSRF, par to ir gana daudz materiālu: http://www.google.lv/search?q=XSRF tur arī būs aprakstīts par tokenu lietošanu.

    Kaut kā tā arī es tagad daru! Velku visu laiku līdzi iekš db user token (ip+user_agent) un pēctam tik čeko, ja šis nesakritīs, tad nebūs lietotāja pieeja :)

  5. protams, GET mainīgajiem kur ir cipari panjemu ar (int)

    rekur piemērs kā man izskatās visi qveriji:

    $event = htmlspecialchars($_GET['event']);
    $id = (int)$_GET['id'];
    
    if ($event == "confirm") {
       $query = sprintf("UPDATE lauks SET completed='yes' WHERE id='$id'") or die(mysql_error());
       $result = mysql_query($query);
       header("Location: view.php?id=$id");
       exit();
    

     

    Tas sprintf Tev tur neko nedod. ko tad teica Tavi logfaili?

  6. Uzstaisiju login skriptu ar cookie viņs kad eju profila met Header allready send.

    Cōkies to me? :O Nav Tev tur ar sessijam šī problēma? Kūrā rindā jau aizsūtīts pirmais headeris? Kāda ir tā rinda un kas ir pēc tam.. :D Parādi skripteli? :?

  7. Tokenus parasti izmanto, lai novērstu XSRF uzbrukumus, teiksim, tu ieliec lietotājam sesijā random id un to pašu id pievieno arī kaut kādai formai. Kad lietotājs nosūta formas datus, salīdzini, vai formas tokens sakrīt ar lietotājam piešķirto tokenu sesijā. Ja sakrīt, viss labi, ja nē, tad pieprasījumu nevajadzētu apstrādāt.

    Kādā gadījumā nesakritīs sessijas tokens ar formas tokenu?

     

    Nū man ir +/- līdzīgi, ja sessijā ir lietotāja ip + user agents, kas sakrīt ar apmeklētāja ip + user agent datiem, tad turpina čekot tālāk utt..

     

    btw, $_SESSION datus 3ša persona taču nekādi nevar iegūt? Kkur lasīju, ja ir register globals on, tad caur url var kkā mainīt $_SESSION datus vai kas tamlīdzīgs. Izklausās jau mazliet pēc wtf? ^_-

     

    hmm.. Cik sagūglēju, tad sesiju hijacking un fixation ir tā lielākā sāpē. Nū tad man liekas, ka esmu +/- pret to pasargāts.. Reģenerēju id, lai pasargātos no fixation un par to hijacking īsti nesaprotu :\ Sākt jukt viss kopa :@

     

    Kā reāli tas notiek? http://phpsec.org/projects/guide/4.html Tēmā par Session Hijacking sanāk, ka sesija darbosies ar pieprasījumu no kkāda:

    GET / HTTP/1.1

    Host: example.org

    User-Agent: Mozilla/5.0 Gecko

    Accept: text/xml, image/png, image/jpeg, image/gif, */*

    Cookie: PHPSESSID=1234

     

    Un tad, ja ar tieši šādu pašu HTTP request (vai kā pareizi sakukt?) konektējos pie servera, tad man būs pieejama cita lietotāja sesija un šo visu procesu sauc par Session Hijacking? :D

     

    Kas tad īsti ir tas:

    GET / HTTP/1.1

    Host: example.org

    User-Agent: Mozilla/5.0 Gecko

    Accept: text/xml, image/png, image/jpeg, image/gif, */*

    Cookie: PHPSESSID=1234

     

    sessijas atstāts cepums?

     

    Bet pret to Session Hijacking esmu taču +/- pasargāts ar šo te

    $session_token = isset($_SESSION['stoken']) ? $_SESSION['stoken'] : false;
    $visitor_token = md5(getip() . $_SERVER['HTTP_USER_AGENT']);
    

     

    ja pareizi esmu sapratis kā tas viss notiek.. :?

     

    Kā sessija vispar zin, ka tas ir tas useris? Viņa atstaj kko lietotājam (cepumu?) un tad skatās vai tas ir tas pats? Vai ari glabā serverī kko no lietotāja puses.. Meklēju google kā darbojas sessijas, bet tracina, neatradu atbildi :O

    aa, doh! http://www.php.net/manual/en/intro.session.php otrā rindkopa ;D

  8. Atkal es.

     

    Nu, tad moku savu autorizēšanās sistēmu. Bet, jo vairāk meklēju info par to, jo vairāk saduros ar nepārliecību savam skriptam :\

    Vēlētos noskaidrot vai man ar šo pietiktu? Kas man tur lieks un ko vēl vajadzētu? Kā būtu labāk.. jo cik dzirdēju, tagad jebkurš var nostopēt sessijas datus utt.. (Bija Alekseja rakstiņš forumā, kkas tāds..) Tāpēc tagad jāsāk vairāk baidīties ^^

     

    function user_authentication(){
    
           global $db;
    
         @session_start();
    
         $user_id = isset($_SESSION['uid']) ? $_SESSION['uid'] : false;
         $session_token = isset($_SESSION['stoken']) ? $_SESSION['stoken'] : false;
         $visitor_token = md5(getip() . $_SERVER['HTTP_USER_AGENT']);
    
         if(is_numeric($user_id) AND $session_token == $visitor_token){
           $uChData = $db->get_row(sprintf("SELECT ID, user_salt FROM " . DBP . "users WHERE ID = %d AND Ses_token = '%s'", si($user_id), si($session_token)));
           if(empty($uChData)){ //Session data belong to noone
             //Destroy useless token and user id
             unset($_SESSION['stoken']);
             unset($_SESSION['uid']);
             return false;
           }else{ //Proceed if we are authenticated 
             //Set authentication data
             $this->uid       = $uChData->ID;
             $this->user_salt = $uChData->user_salt;
             $this->loggedin  = true;
             //updates last seen time
             $this->update_last_seen_time();
             //Regenerate session ID to prevent session fixation attacks
             session_regenerate_id();
             return true;
           }
         }else{ return false; }
       }
    

     

    http://shiflett.org/articles/session-hijacking šeit smēlos nedaudz informāciju, bet wtf? Es īsti nesaprotu par to pēdējo koda daļu, kāda jēga vienkārši sessijā uzģenerēt kkādu token? :O Ko pēc tam viņš ar viņu dara? Man token vairāk asociējas ar kko, kas identificē no lietotāja puses šajā gadījumā.. Kā būtu, ja katru reizi, kad lapa tiek atjaunota, tiktu izsniegts lietotājam jauns token cepumā? :?

  9. Ar konstantēm īpaši neaizraujos, tikai tik daudz cik galvenos settingus nodefinēt.

    Nu laikam jau viss skaidrs, vienkārši iepriekš darīju vienas klases ietvaros aptuveni šādi: $_SESSION[$this->sess_prefix . '_token']

    Bet laikam darīšu kā rādīji, ar konstantēm.

  10. Nu tad liec prefiksus sesijas nosaukumiem, vai, izveido tos sesiju nosaukumus kā konstantes, un tad lieto kodā visur tās. Ja rodas problēmas, vienkārši pārdefinē konstantes vērtību un problēma atrisināta.

     

    Ar drošību sakara tam nav, cik saprotu, uztaucies par to, ka kaut kādas koda daļas varētu izmantot nejauši vienu un to pašu konstantes nosaukumu?

    Nu jā, aptuveni. Bet man tagad viss griežās klasē ar privātajiem operātoriem un funkcijam. Mācos tagad oop un pie reizes taisu lietotāju cori.. Tur apakšā ir autentifikācija, iziešana no tiešsaistes utt..

  11. Piemēram $_SESSION['atsleega']

     

    Atslēgas nosaukumam ir liela nozīme drošības ziņā? Varbūt tas maina ko citu.. Piemēram, ja ir viens kaut kāds API, kurš visu laiku izmanto $_SESSION['atsleega'], tad varētu rasties kāda problēma.. :? Par šādu gadījumu es kkur lasīju, kad centos noskaidrot atbildi uz šī topika tēmu ^^

×
×
  • Create New...