In kaj je napaka?

Že če programiraš se moraš seznati z orodji, ki so ti na voljo za debugiranje - v tem primeru error log.

Drugače vidim da po besedi LIMIT nimaš presledka...

Mika, to je pogled v adminu (backend). V frontendu je samo končna cena, ki seveda vedno vključuje DDV.

Torej nekako razumem, da mi predlagaš, da na nivoju naročila pustim tako kot je, na nivoju računa (ločen sistem/tabele) pa pretvorim v popust na postavke.

V bistvu je res tako edino možno to narediti, ker moram na nivoju naročila imeti nespremnjene postavke, oz. moram vedeti koliko je popust na naročilo, ker recimo za SAOP (s katerim delam integracijo) moram ta popust na naročilo uvoziti kot postavko z negativno količino (-1), ki potem poskrbi za pravilen končni znesek.

Matjaž, se strinjam, sicer pa če daš popust na ceno brez DDV je to še boljše kot na ceno z DDV, tako da mislim da se noben ne bi bunil, bi pa trgovec sam sebe oškodoval :)

No vidite, 2 odziva 2 različni mnenja (pred in po davkih) :)

technolog, to isto zadevo narediš z extract($_POST);

Drugače obstaja importrequestvariables() ampak kot vidiš je deprecated od 5.3 naprej in odstranjena od 5.4 naprej.

Kakorkoli, zadeva je nevarna in tako kot je technolog napisal, velja samo za hiter hack.

Pozdravljeni,

zanima me, ali mi lahko kdo pomaga, kaj točno naj bi v programu za spletne trgovine naredil, ko uporabnik odda naročilo s kuponom za npr. 5€.

Najprej sem naredil tako kot je na tej sliki, torej od končne cene (z davki, splošnimi popusti...) odštejem znesek kupona, vendar to pomeni da potem prodajalec plača preveč davka.

Razmišljam, da bi dodal kupon kot postavko z negativnim zneskom not, ampak tudi tam vpliva na znesek davka - po možnosti narobe, ker lahko naročilo vsebuje mešane davčne stopnje (10,5% in 22%). Razen, če ga moram dodati po neki določeni davčni stopnji?

Kakšen nasvet? :)

Glede na to,

- da trojke ni in ni na spregled, čeprav so že zdavnaj pravili, da samo še dokumentacijo zrihtajo

- da je v bistvu bolj proceduralni kot OOP FW

- da niti v3 ne bo prinašala modularne arhitekture (controller še zmeraj ne more biti v paketu, brez overloadanega/shekanega Loaderja)

- da EllisLab opušča "skrbništvo" in išče novega skrbnika

... lahko rečemo, da je CodeIgniter obsojen na pozabo.

Osebno bom prešaltal na Laravel, en API sem že naredil na tej osnovi, drugega pa ravno začenjam...

skynet:

Če.

Kdo pa pravi da ne morejo vdret v spletni servis/program za shranjevanje gesel in ti odtujit vseh gesel? Možnost, da ti nekdo hekne gmail, facebook in še kakšen račun, da ugotovi po katerem sistemu si nastavljaš gesla je po mojem mnenju manjši od tega, da ti vdrejo v spletno hranilnico gesel. Po samo enem geslu pa nihče ne bo vedel tvojega sistema. Pa vso srečo brute forcat npr 25 znakov.

Problem ni, da bodo vdrli v spletni servis, ranljivosti je več:

- geslo po takem sistemu boš vpisal v sumljiv/slabo zavarovan sistem ki shranjuje gesla v plaintextu. Če bo ta baza kdaj odtujena bo pisalo not tako: skynet@gmail.com / pa$$w0rd#naziv_servisa . Nato lahko poizkusijo odpreti gmail z geslom pa$$w0rd#gmail in tako nadaljevali z ostalimi servisi. Upam da razumeš kaj mislim

- geslo ti lahko sunejo z network snifferjem, če ga vpisuješ na HTTP stran / FTP / ne-ssl poštni predal ali SMTP strežnik (pri vseh teh zadevah se geslo prenaša v plain textu)

- razne ranljivosti tako na strežniku kot na klientu (primer heartbleed je aktualen in vsem razumljiv)

V glavnem, če ti sunejo eno geslo ali sumiš da so ti lahko sunili (servis ob incidentih vedno priporočajo: please change your password), je sistem komprimitran.

Po samo enem geslu pa nihče ne bo vedel tvojega sistema.

Na internetmojster.com imaš geslo pa$$w0rd#internetmojster (v leet speaku), res ne bi znal povezati 1 in 1? Misliš da si edini ki uporablja tak sistem, jok brate

Pa vso srečo brute forcat npr 25 znakov.

Fiksni del poznaš, dolžino tudi, nabor znakov tudi [a-Z0-9]. V bistvu brute force sploh ni potreben... Samo pretvoriš naziv servisa v leet speak.

Saj lahko to uporabljaš zaradi mene, težim ti samo zato ker je sistem pre-enostaven, če ne dodaš nekega variabilnega dela.

skynet:

Ne uporabljam ničesar. Za login v spletne strani imam kombinacijo fiksnega gesla ki znaša cca 10 znakov in potem še za vsako stran posebej izpeljanko iz domene spletne strani. Primer (ampak seveda ne točno tak ki ga sam uporabljam):

FB: Pa$$w0rD-$%&F4c3b00K&%$

IM: Pa$$w0rD-$%&1nt3rn3m0j$t3r&%$

To se, vsaj meni, zdi dokaj bullet proof, zapomnit si moraš samo sistem :)

Tudi sam sem nekaj časa uporabljal tak sistem. Problem pa je da je tako močen kot njegov najšibkejši člen.

Če hackerji dobijo en tvoj password in uspejo razbrati smisel gesla napram domeni/nazivu servisa, je sistem razbit. Tistih par preostalih upper/lower case in leet speak znakov ni problem brute forcati.

Če se stran ne prikaže in hkrati ni nobenga sporočila o napaki je možno

1. da se je zgodil PHP error, error reporting pa je ugasnjen

2. error reporting je morda prižgan, a se je error izpisal ravno sredi ene HTML značke - če daš "view source" boš videl error

3. error je verjetno odvisen od seje ali kakšnega piškotka, zato ti na enih kompih dela na drugih pa ne

itd.

Ha

http://httpcolonforwardslashforwardslashwwwdotjenniferdanieldotcom.com/