Problem ze skryptem kalkulatora

pytanie zadane 19 stycznia 2016 w JavaScript przez Michał Tofik Dulik Nowicjusz (150 p.)

Witam uczę się programować w js i napotkałem taki oto problem: gdy odejmuje 2.3-0.3 to wychodzi 1.9999999999999998 :/ coś tu jest nie tak.... Oto Kod:


    function addletter(x){
        var box = document.getElementById('ekran');
        box.innerHTML +=x;

        if(x=='c'){
            box.innerHTML='';
        }
    }

    function oblicz(){
        var box = document.getElementById('ekran');
        x=box.innerHTML;
        x=eval(x);
        box.innerHTML=x;
    }

2 odpowiedzi

odpowiedź 19 stycznia 2016 przez niezalogowany
wybrane 19 stycznia 2016 przez Michał Tofik Dulik

Najlepsza

Wynika to z niemożliwości zapisania dokładnie wartości 0.3 w systemie binarnym, którego używa funkcja eval. Tak samo jak w systemie dziesiętnym nie możesz zapisać dokładnie 1/3, ponieważ jest to 0.333333333333333 -> i kiedyś na te trójki skończy się miejsce, tak 0.3 w eval - jest po prostu najbardziej do tej wartości przybliżane.

Zaokrąglaj wyniki do 14 miejsca po przecinku i powinno działać : )

komentarz 19 stycznia 2016 przez Michał Tofik Dulik Nowicjusz (150 p.)

Dzięki Wielkie!

odpowiedź 19 stycznia 2016 przez Comandeer Guru (601,110 p.)

Pomijając sam problem opisany już w poprzedniej odpowiedzi, należy dodać, że użycie tutaj eval jest błędem, bo pozwala na WYKONANIE JAKIEGOKOLWIEK KODU. Lepiej dzielić string po znakach działań + parsować wszystko inne na liczby. Całkiem możliwe, że będzie nawet szybciej działać ;)

Pokaż 9 poprzednich komentarzy

komentarz 20 stycznia 2016 przez event15 Szeryf (93,790 p.)

Mnie zastanawia dlaczego możliwość wykonania jakiegokolwiek kodu w js po stronie użytkownika jest błędem?

Nadal nie widzę związku..

Równie dobrze możesz sobie otworzyć konsole na stronie z tym kalkulatorem i wklepać self-XSSa, albo napisać hasło do maila na czole...

Jak sobie sam nie zrobisz krzywdy na stronie z tym kalkulatorem.. to nikt inny przez funkcję javascriptu też tego nie zrobi.

U panie. Z takim podejściem to daleko nie zajdziesz.

Brak zrozumienia totalnych podstaw zachowania bezpieczeństwa to równia pochyła ku głośnemu skompromitowaniu programisty. Tu jest przykład w JS.

Jest zasada, która mówi - nigdy nie ufaj użytkownikowi swojego programu/swojej strony. Myślisz, że to jest zasada z dupy wzięta? Patrząc przeszłościowo na PHP chociażby to przez taką ignorancję jaką prezentujesz język ten zaskarbił sobie tyle hejtu. Korzystanie ze zmiennych globalnych, listery plików wykonywane właśnie za pomocą funkcji, które umożliwiały wykonanie dowolnego polecenia po stronie serwera.

Łatwość nauki podstaw PHP sprawiła, że wielu fircyków myślących, że potrafią programować wypuściło w świat zupełnie niezabezpieczane dane. Przez to tematem przewodnim milw00rma były głównie skrypty PHP (joomla, wordpress, phpBB, miliony wtyczek do nich). Pojawiła się wtyczka google maps do przema - miliony stron na świecie padło, bo autor nie pomyślał, że poza ciekawą funkcjonalnością istnieje coś takiego jak brak zaufania do odbiorcy produktu.

JavaScript nie jest już językem który działa tylko po stronie klienta - spójrz na node.js i inne frameworki. JavaScript praktycznie od serwera po klienta znajdzie wszędzie zastosowanie, a tak ignoranckie podejście do spraw bezpieczeństa niestety nie poskutkuje jedynie wykradnięciem danych.

Jeśli uważasz że zamiana eval() na inną funkcję jest zabezpieczeniem rodem z banków, to naprawdę mało masz wspólnego z programowaniem. Ale tak samo to, że ktoś pozna moje imie lub ktoś pozna mój adres email to jest kradzież danych osobowych chroniona prawem cywilnym. Za takie rzeczy sam się sądziłem i takie sprawy zawsze się wygrywa.

jeżeli człowiek się uczy programować w danym języku, to z miejsca powinien być uczulany na takie rzeczy jak filtrowanie danych - nie bo to fajnie wiedzieć, tylko jest to obligatoryjne. I każdy powinien znać chociaż podstawowe metody. Nie mówię tutaj o specjalistach od zabezpieczeń, którzy są freekami i wszystko powinno być dla nich szyfrowane, bez możliwości cofania strony, filtrowane milionem funkcji, sanityzowane i przetwarzane w rozproszonych serwerach. Mówię o głupim ifie, który sprawdzi czy rzeczywiście otrzymujemy od użytkownika to, czego oczekujemy. Czy wykorzystaniu innej funkcji, która działa praktycznie tak samo a jest dużo bezpieczniejsza.

komentarz 20 stycznia 2016 przez niezalogowany

Zgoda. Kawał dobrej roboty w tłumaczeniu mi i pokazaniu realnych przykładów (chociaż ich zaistnienie naprawdę wymaga ogromnego wkładu pracy użytkownika).

Dziękuje za cierpliwość. Muszę bardziej myśleć w kategoriach social engineering.

komentarz 20 stycznia 2016 przez niezalogowany

event15, Comandeer 'to podejście' dzięki takim ludziom jak wy - się zmienia : )

Wnioski: trzeba myśleć o wszystkim, wszędzie, nawet po stronie klienta w javascripcie, nawet tam gdzie osoby trzecie 'nie mają' dostępu.

komentarz 20 stycznia 2016 przez event15 Szeryf (93,790 p.)

Taki przykład niedawno tu na forum byl. Chłopaczek sobie stworzył stronę, na której można było wgrać plik. W ogóle nie zabezpieczył się. W ciągu kilku minut wgrano mu plik php który służy jako coś w rodzaju trojana. Gdyby nie wewnętrzne zabezpieczenia serwera to ktoś miałby poważny problem bo stworzył furtkę do zrobienia wielkiego bajzlu w serwerowni na której stoi conajmniej kilkaset stron użytkowników. Wyobraź sobie, że ktoś trzymał tam jakieś dane które miały wartość pieniężną. Myślę że nastolatek nie miałby szans zapłacić kar tak dużej liczbie użytkowników i serwerowni.

komentarz 20 stycznia 2016 przez niezalogowany

Hej, z góry zakładasz, że nie mam pojęcia o bezpieczeństwie aplikacji internetowych...

Po prostu trochę zlekceważyłem problem self-XSSów - stąd ta dyskusja.