Blitz

 

 

 piemēram, username?

Kas vainas username Jack&Jil, vai <B>litz ? Vai "Blitz"? 

 

 

Vai datumā. Vai epasta adresē.

Tie ir specifiski formāti, attiecīgi validē. Ja eksistē reāli ierobežojumi (nevis programmeru izdomāti, jo redz kautkāda browserī kautkā specifiski attēlojas) tad pret tiem validē, no problems. Par šo nediskutēju.

Tāpēc ka <, >, &, " ir pilnīgi normāli dati/chari, un lai normāli viņi arī glabājas.

Un vel DB laukos ar ierobežotu garumu. šāda makslīga datu papildināšana zog tikai vietu, un pie kā tas var novest? Kavacky vairs savu kruto username nevarēs ievadīt, kaut pēc simbolu skaita to vajadzētu varēt.

 

 

When someone does a keyword search for 'amp', they get "Jack & Jill". Why? Because you've corrupted your data.

http://stackoverflow.com/questions/11253532/html-xss-escape-on-input-vs-output

 

 

Atnāk developeris Y un pie datasources R piekabina frontendu C, kas šos datus eskeipot aizmirst (one time is enough).

Atnāk developeris W, uztaisa "konsoles" frontendu un domā ... wtf?!

Tas ka plain PHP output escape by default nenotiek, bet template engine notiek un tam vairs nav jāpievērš speciāla uzmanība, izņemot vietās kur tu specili forcē templeitam rādit neeskeipotu saturu.

Es ar padomāju: "Tik gudri cilvēks runā, bet kāds vēl XSS?" :D

Visu ievaddatu pārbaude taču ir pamatu pamatos.

 

Nesatraucies, es diskutēju par validitēšanu nevis nevaliditēšanu.

Personīgi es tādu lauku nevalidētu, bet ja būtu nepieciešamība, piemēram, kādam ļoti sakārtotam saitam, tad atļautu burtus, atstarpes un pieturzīmes.

Tu laikam nezini par ko vispār runā

 

 

2. Datu validitācija ir normāla prakse. Vārds ir vārds un e-pasts ir e-pasts.

Kautkāds wtf, kurš te runā par ne-validēšanu? Tagad pastāsti man  <strong>text</strong> ir valīdi ievaddati, piemēram user about me laukā, vai nav?

Vel labāk glabāt eskeipotus datubāzē :D Vai kā biedrs webi iesaka, validēt. "Sorry, input data can not contain XSS" :D

Inputa html eskeipings? Jūs jokojat? 

http://lukeplant.me.uk/blog/posts/why-escape-on-input-is-a-bad-idea/

Nu nez, labāk jau pure php .. php visa būtība ir būt embeded html templeitam.

 

 

Jo kad visādas templeitsistēmas (piem tas pats Twig) sāk darīt kaut ko šādu:

{% for user in users %}
    * {{ user.name }}
{% else %}

.. t.i. redefinēt pašas valodas konstrukcijas, tad man liekas, ka tālāk vairs nav kur.

 

1) Pure php pieļauj vairāk kļūdu (xss)

2) Pure php ir mazāk lasāms (subjektīvi), "verbozāks"

3) Templeitu valodas domātas ērtībai, ja developerim tas ir ērtāk, tad ir jaizmanto! Lielāka produktivitāte, mazāk kļūdu, code reuse utt

4) Kompilējamiem templeitiem tā pat nav nekāds overheds, tad kāpēc nē? Tad jau arī sass/less priekš css ir "tālāk vairs nav kur"

Apmēram, jau gadus divus esmu atteicies no jebkāda PHP klienta pusē

Mhm, tālāk komentu jau laikam lasīt nav jēgas

Tieši tie widgeti iekš Yii ir vis tracinosaka lieta

Blade

Pros:

1) Kods pārskatāmāks, vieglāk uzturams, strukturējams (partials)

2) Līdz minimumam samazināts xss

3) Layouts / Template inheritance

4) Learning curve praktiski neeksistē, 0.5h rtfm un mauc. 

5) Lietot pure php kur vajag / ja vajag

Cons

1) Nav normāli nodrošināta JS nodalīšana, pa modīgo, lapas apakšā (lietot atsevišķu sekciju paršalu JS gadijumā nevar)

2) Nav tādas oficiālas standalone versijas

Ir relācijas, pat caur pivot tabulām, pēc default mass assignment ir visi/neviens, pašam ar rociņām tad jāpatīra/jāpieliek klāt. Vel ide-helper saliks phpdoc model ar propertijiem/relācijām.

 

 

Tad pasaki man, kāda velna pēc tas būtu jāpacieš ja eksistē lieliskas alternatīvas kur kaut kas tāds nenotiek?

Symfony?

Varētu būt jautri tur strādāt :D

Vienreiz biju uz aurumit darba interviju, radās diezgan profesionāls un pozitīvs iespaids.

Kāpēc alga ielikta "pēdiņās"? Vai ar to jāsaprot ka algas vietā tiks sniegti "citi pakalpojumi"?

 

• WordPlate is built on top of Laravel and Symfony components and utilizes WordPress as its dependency through PHP Composer.

:D

Kreatīns uzsūcas zarnās tāpēc vislabāk to ir nogādāt pa taisno tur. 

CTO uzņēmumā ir savas atbildības un tikai būtu normāli ja viņs piep.. pie šādiem formulējumiem, vai būtu skeptisks, vai aizrādītu, liktu labot utt. 

Ko tev tas API dara? Cik rekvesti uz API tiek veikti viena rekvesta uz WEB ietvaros?

Paldies, tas ir tas ko vajag. 

Class jau ir tikai syntactic sugar, to vajadzētu atrisināt arī ar es5. Pašlaik problēmu risinu ar injektojot A un B instances iekš C, bet roku taisnumam tas nepalidz

Jā n reižu pārlasīts bet tā pat nevaru saprast kā to implementēt. Ja taisu bez konstruktoriem, plain objektus, tad no problems. 

Tā izskatās, prātu man sačakarē arī tas, ka katram objektam ir vajadzīgs konstruktors, un to definē kā funkciju (cik sparotu), savukārt paša objekta body ir kā funkcijas prototips. Rezultātā man vajadzīgs lai protopips extendojas no cita prototipa. Varbūt kautkas pašā būtībā ir galīgi šķersām.