ugrás a tartalomhoz

Archívum - Május 2014

május 14

Website Deployment: Let Us Count The Ways!

inf · 2014. Május. 14. (Sze), 21.38
Összefoglaló néhány webes deploy eszközről
 

Validációs tervezési hibák

inf · 2014. Május. 14. (Sze), 02.03
Szép napot!

Kíváncsi vagyok, hogy mit gondoltok a php validációról. Jó, ténylegesen nincs ilyesmi, de én nagyon furcsának találtam az alapvető hozzáállást a validáláshoz az összes kódban, amit eddig láttam. Gyakorlatilag már a kiindulásnál elbuknak, mert eleve rossz stratégiát választanak.

Alapból valahogy így szokás nekifutni php-ben a validálásnak:

// lib/form/ContactForm.class.php
class ContactForm extends sfForm
{
  protected static $subjects = array('Subject A', 'Subject B', 'Subject C');
 
  public function configure()
  {
    $this->setWidgets(array(
      'name'    => new sfWidgetFormInput(),
      'email'   => new sfWidgetFormInput(),
      'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)),
      'message' => new sfWidgetFormTextarea(),
    ));
    $this->widgetSchema->setNameFormat('contact[%s]');
 
    $this->setValidators(array(
      'name'    => new sfValidatorString(array('required' => false)),
      'email'   => new sfValidatorEmail(),
      'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))),
      'message' => new sfValidatorString(array('min_length' => 4)),
    ));
  }
}
Symfony dokumentációból másolt kód - Form-Validation

Ez még a szerencsésebb eset. A szerencsétlenebb az, amikor külön controller-ben van a validáció és külön view-ban az űrlap létrehozása, és lapozgatni kell egyikről a másikra, hogy lássuk mi micsoda.

Miért rossz ez (legalábbis szerintem)?

Ha security-ről van szó általában mindenki a whitelist-es megoldásokat biztonságosabbnak tartja, mint a blacklist-eseket, mert könnyű kifelejteni, embereket, akiknek tiltani akarjuk az alkalmazás használatát.

május 12

MEGOLDVA Karakterkódolás hiba POST után Firefoxban

csabessz47 · 2014. Május. 12. (H), 19.22
Sziasztok,

Tudom, lerágott csont a karakterkódolós szerencsétlenkedés, de egyszerűen nem jutok előrébb ezzel a problémával.

Egy már majdnem kész oldalon van egy pici bug:
Post után a karakterkódolás a Firefoxban visszaáll ISO-8859-2-re, így minden ékezet rosszul jelenik meg.
Következő oldalbetöltéskor már ismét rendben van az utf-8.

A head:


<!DOCTYPE html>
<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <![endif]-->
<!--[if gt IE 8]><!--> 
<html class="no-js" lang="hu" xmlns:fb="http://ogp.me/ns/fb#" xmlns:fb="http://www.facebook.com/2008/fbml" xmlns:og="http://opengraphprotocol.org/schema/" xmlns:fb='http://developers.facebook.com/schema/'> <!--<![endif]-->
  <head>
	<base href="/" />
	<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
	<meta http-equiv="content-language" content="hu" />
Chrome, Opera, IE böngészőkben semmi gond nincs, Firefoxban post után rossz.
Van ötletetek, esetleg tapasztalat, hogy mitől fordulhat ez elő?

Köszönöm előre is.

Szerk: Azóta kipróbáltam ezt, de ez sem működik:
<meta charset="utf-8">
 

JQ - Each - táblázat kiirasa - BUG ?

53éves_nagypapa · 2014. Május. 12. (H), 11.53
Egy tömb tartalmát iratnám ki.
Egy kétoszlopos táblázat lenne, bal oszlopban a kulcsok jobban az értékek.

Az each indulása előtt kiirom a table tagot.
Majd a ciklusban a tr és td tagot,
bele az adatokat majd lezarom a td tr tagokat,
és a ciklus után kiirom a /table vege tagot.

/Ahogy azt php-ben szoktam csinálni foreach esetén./


IGENÁM, DE A JQ AZ ELEJÉN AMIKOR KIIROM A TABLE TAGOT
magától kiegészíti A LEZÁRÓ /TABLE taggal.


Pedig azt majd én zárnám le a ciklus után.
Ettől ilyen lesz a táblázat.:
<table></table>
<tr><td></td></tr>

És ráadásul a ciklus után megirt /table -t meg nem irja ki.

Mi az okosság ilyenkor ?
 

május 11

MYSQL

kasza68 · 2014. Május. 11. (V), 18.56
Sziasztok!
Hogyan tudok olyan lekérdezést készíteni egy elég nagy adatbázisból, hogy pl. 2000 recordból 500-at szeretnék kiválogatni (Egységes léptékben ... ha lehet) úgy hogy az első és az utolsó recordot is tartalmazza a lekérdezés.

Előre is köszönöm, ha valaki tudja a választ.
 

PHP - phar archive

inf · 2014. Május. 11. (V), 03.43
Ha jól nézem a PHAR kb 1.5x lassabb, mint a normál PHP, viszont sok előnye van ezzel szemben:
- egyszerűbb másolni, telepíteni
- még véletlenül sem keverednek az adatok, az alkalmazás kódjával, így könnyebb róluk backup-ot készíteni, ami szintén lehet phar formátumban
- van lehetőség titkosításra és digitális aláírásra, elvileg talán még a sérült fájlokat is kiszűri, bár nem tudom, hogy checksum-ot mennyire néz automatikusan

Érdekelne, hogy mi a tapasztalatotok vele, illetve a vélemények is érdekelnek. (Csak most kezdtem el nézni, hogy miket tud.)
 

május 8

PHP - melyik zip kiterjesztés?

inf · 2014. Május. 8. (Cs), 16.31
Melyik php zip kiterjesztést ajánjátok, egyáltalán van különbség köztük?

- zip
- zlib
- phar
- bzip2

(Ha lehet, nekem valami olyan kéne, ami jelszót is tud elfogadható titkosítással.)
 

Git, phpunit, Windows

Steve31 · 2014. Május. 8. (Cs), 11.11
Sziasztok!

Olvastam itt egy jó a cikket a gitről, ehhez kellene segítség. Gitem meg van és van phpunit is. Létrehoztam a phpunit futtatásához egy scriptet, a következőt használtam fel: Git és phpunit. Ebben leírja, hogy windows alatt a php -f parancsot futtassam le a fájllal. A fájl meg van. A pre-commit hook-ba bele írtam és mégsem fut le, csak kiírja, hogy "php -f fájlnév". Hol rontom el?
 

Statikus tábla tárolása adatbázisban vagy talán jobb xml-ben?

janoo · 2014. Május. 8. (Cs), 08.26
Helló mindenki!

Egy elég fura kérdésem lenne hozzátok, és kíváncsian várom válaszotok:

Lehet nem túl jól fogalmaztam hogy statikus tábla, de lényegében egy olyan db tábláról lenne szó, ami sosem változik.
A LEGO szettek és a LEGO alkatrészek közötti kapcsolatot hivatott tárolni, azaz melyik szettben melyik LEGO alkatrész van, és abból hány darab.

Ennek megfelelően ennyi a tábla tartalma: set_id, part_id, quant

Na most a bajom a következő: átlagba minden szettben van minimum 60 féle alkatrész, tehát egy szettnél akkor ez 60! bejegyzést jelent. Úgy hogy a szettek töredéke sincs még lementve ebben a formában, már így is van ebben a táblában több mint 94000 bejegyzés!! Ez max. a szettek 10%!

A másik része a dolognak, ez sosem változik. Egyszer elmentem, és kész. Onnan már csak néha lekérem, ha a látogató meg akarja tekinteni az alkatrészlistát. Tehát tényleg egy tök statikus dolog.

Az jutott eszembe, mi lenne ha simán xml fájlokban tárolnám ezeket. Mégpedig úgy, hogy a szett száma a fájlnév, pl.: 8052.xml, és akkor két dolgot mentenék bele, part_id és quant. Ez így kb 6000 fájl, és csak annyit kell néznem, hogy $setId.".xml" van-e vagy nincs :)

Szerintetek ezzel kímélném a db-t?
Így is van benne jócskán adat (már most is több mint 10Mb :) )

Előre is köszi a véleményeteket
 

május 6

Bad request vagy access denied?

inf · 2014. Május. 6. (K), 03.11
Szerintetek olyan esetben, amikor az illetőnek nincs joga az adott művelethez és mellette még formailag hibás kérést is küld, akkor melyik hibaüzenetet adjam vissza neki?

Ha a business logic felett ellenőrzöm a jogosultságot, akkor a bad request a könnyebben megvalósítható, ha a representation felett ellenőrzöm a jogosultságot, akkor az unauthorized a könnyebben megvalósítható. Vajon biztonsági kockázat e, hogy először a formai hibákat ellenőrzöm, és csak utána a jogokat?