Javascript egenheter

Alla programeringsspråk har sina egna egenheter och typiska drag. En del av dessa ser man inte alltid nyttan av direkt, men samtidigt används de flitigt i tillämpningar och bibliotek. Två av dessa för Javascript är IIFE (iffy), samt deras definition av objekt.

IIFE

IIFE står för immediately invoked function expression och uttalas ”iffy”. Iffe innebär att man i samma sats deklarerar en anonym funktion och dessutom anropar denna funktion. IIFE förekommer ofta som ”wrapper” kring kod och används bland annat för händelsehantering och i jQuery.

Exempel:

var speed =(function(){
var dist=30;
var time=45;
return dist*60.0/time;
}());

Observera parenteser.

Objekt

Ett standardobjekt i Javascript är inte som i exempelvis C++ en instans av en klass.I stället så är ett objekt en samling data och funktioner som tillsammans representerar en modell av ett objekt. Antal attribut och metoder är inte konstanta utan man kan lägga till nya attribut och metoder. Det är viktigt att man kommer ihåg vad man lägger till då det inte finns en klass som fungerar som karta eller ritning.

Attribut och metoder kan nås antingen med punktnotation som i Java eller C++, eller med hakparenteser.

Ett objekt kan skapas med sina attribut kommaseparerade inom {}.

var hif = {
name: ‘Helsingborgs IF’,
arena: ‘Olympia’,
seger1: 1929
};

Man kan också skapa ett tomt objekt med new Object() och sedan lägga till attribut och metoder.

var mff = new Object();

mff.name=’Malmö FF’;
mff.arena=’Swedbank Stadion’;
mff.seger1=1944;

Det finns också ett sätt att skapa objekt med en form av konstruktor.

function Team(name,arena,seger1){
this.name = name;
this.arena = arena;
this.seger1 = seger1;
};

Man får sedan objekt med följande anrop:

var hif = new Team(‘Helsingborgs IF’,’Olympia’,1929)

Ett lite smidigare sätt om man vill ha flera objekt med samma namn på attribut.

 

ZigBee Security

ZigBee är en standard för trådlös kommunikation som används mycket för sensorer i smarta hem. Det finns dock en del säkerhetsproblem med dessa. Inte minst gällande de profiler som används för vissa tillämpningar. Exempelvis finns det default-nycklar som man kan falla tillbaks på.

På blackhat 15 hölls ett föredrag kring detta. Jag länkar till föredraget härifrån för att ha en referens. Dessutom finns det ett paper. PDF-fil till deras paper. (OBS! pdf i ny flik)

Proxy ARP

I samband med att konfigurera statiska routingtabeller i en router så stötte jag på en sak som gjorde mig konfunderad.

När man skapar en statisk route så anger man normalt IP-adress för nästa hopp. Med hjälp av denna adress så används sedan ARP för att få MAC-adress till nästa-hopp och kan skapa korrekt lager2-frame.

Nu visar det sig att man för vissa routrar, exempelvis CISCO, inte behöver ange IP-adress utan det räcker med interface. Det som gjorde mig konfunderad är hur man då kan få reda på en MAC-adress för att skapa korrekt meddelande på lager 2. Lösningen var att det används en teknik som kallas Proxy ARP. Med Proxy ARP så frågar en router efter MAC-adress till slutdestinationen med ett ARP-meddelande. Detta trots att denna IP-adress inte finns på detta LAN. ARP-meddelanden skickas dessutom med boradcast layer2, vilket gör att de inte får routas. Hur får då vår router rätt adress? Anledningen är att en router som har en väg till målet svarar på ARP-förfrågan med sin egen MAC-adress. Därefter så kan vår router skapa rätt adress. Alltså fungerar det, men jag är inte helt nöjd utan har ett par funderingar?

  1. Prestanda. Blir det fler ARP-förfrågningar?
  2. Säkerhet. Tanken är att vi vet vilken router som ska svara på ARP-förfrågan. Men tänk om en annan router svarar i stället för den äkta. Då kan paketet visserligen nå målet men med en annan väg än den vi tänkte. Om man nu väljer statisk routing så borde vi se till att ange fullständig information. Om inte kan väl ett routingprotokoll likt OSPF användas.

Jag får kanske kopplaupp och testa. Jag skulle också fundera kring en miljö där man kan mäta lite mer statistik för att se prestanda.

Risker med internet of things

Visst är det coolt att fler och fler saker blir uppkopplade. I stället för att behöva bläddra i en kartbok när vi är ute och kör bil på semestern så visar vår GPS oss vägen. Om bilen dessutom är uppkopplad så kan en ny rutt föreslås för att undvika trafikstockningar och vägarbeten.

I medicinska tillämpningar så kan vi tycka det är bra med att diabetikers insulinpumpar kan mäta blodsockernivån och anpassa dosen efter behov.

För utvecklare idag så är det väldigt enkelt att lägga till funktioner för att ge extra upplevelser genom att nätansluta enheter. Det finns bra APIer och utvecklingspaket som hjälper till. Tyvärr så glömmer man ibland säkerhetstänket och slutresultatet blir inte riktigt som man tänkt. Som exempel så kan man ta följande filmklipp som visar alternativa sätt att kontrollera en bil.

Det finns också rapporter på att man kan fjärrstyra pacemakers vilket naturligtvis kan ha katastrofala konsekvenser. University of South Alabama gjorde ett experiment på en docka, iStan.

Personligen anser jag inte att vi ska stoppa utvecklingen. Däremot är det viktigt att utvecklare lär sig att tänka på säkerheten. Under tiden får man som användare vara vaksam och själv minimera riskerna.