Windows 10: Kinek-mit-mikor?

A mai nap a Microsoft bejelentette a Windows következő, “Threshold” kódnevű változatának első előzetesét. Az előzetessel (preview) kapcsolatban nagyon fontos megérteni, hogy a cég jelentősen más stratégiát fog követni a végleges változat előtti kiadásokkal, mint korábban. Biztosan sokan emlékeznek még az alfa-béta-RTM időkre, amit azután felváltott a CTP-CTP-RC-RTM sorozat. Az új Windows verzió a mostani tervek szerint több előzetes, azaz preview formájában fog megjelenni, de nem is az elnevezés a lényeg, hanem hogy az egyes előzetesek jól meghatározott célközönségnek fognak szólni.

Ez a mostani az ún. enterprise preview, azaz a nagyvállalati ügyfeleknek szóló előzetes, amit a következő egy év folyamán újabb előzetesek fognak követni, várhatóan ebben a sorrendben és időzítéssel:

Jelen pillanatban senki sem tudja pontosan megmondani, hogy az egyes verziókban mi lesz benne, csak az biztos, hogy amit a mostani Windows 10 előzetesben látunk, az még sokat fog változni. Bár a mostani előzetesben is találunk leginkább végfelhasználóknak szóló újdonságokat (több desktop, modern alkalmazások ablakban, Start menü, keresés stb.), ezek még jócskán változhatnak, hiszen ennél a kiadásnál nem ezekre koncentráltak a fejlesztők.

Mit érdemes most kipróbálni? Elsősorban a nagyvállalatoknak szóló újdonságokat, de természetesen lehet visszajelzéseket küldeni minden más funkcióval kapcsolatban is, hiszen a fejlesztőcsapat minden feedbacket komolyan vesz. Sok idő van még a végleges verzióig, sok képlékeny rész van, ami majd a visszajelzések alapján fog kialakulni. Csak épp kimondottan sokat nem érdemes olyan dolgokon pörögni, amik nem az adott kiadás fókuszába esnek.

 

Technorati-címkék: Windows Threshold

GUID definiálása XSD-ben

XML dokumentumokban gyakran előfordul, hogy egy elem vagy attribútum GUID értéket tartalmaz. Mivel egy XML a hozzá tartozó XSD nélkül fabatkát sem ér, nem ritka feladat, hogy XSD-ben elő kellene írnunk, hogy az adott érték csak GUID lehet. Az XSD sokféle beépített típust támogat, de sajnos GUID nincs, így marad a klasszikus regexes megoldás:

<xs:schema ...>

  <xs:simpleType name="guid">
    <xs:restriction base="xs:string">
      <xs:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-
                         [0-9a-fA-F]{4}-[0-9a-fA-F]{12}" />
    </xs:restriction>
  </xs:simpleType>

Ha ez megvan, akkor pontosan úgy hivatkozhatunk a saját guid típusunkra, mint a beépítettekre:

<xs:attribute name="id" type="guid" use="required" />

Érdemes megfigyelni, hogy a regex elején és végén nincs $ és ^ jel, ugyanis a minta mindig a teljes értékre vonatkozik.

 

Technorati-címkék: XML,XSD

HTTPS: rendesen vagy sehogy

Volt szerencsém Bolognába látogatni nyáron, és örömmel láttam, hogy a repülőtéren ingyenes wifi szolgáltatás van. Lehet, hogy már ekkor gyanakodnom kellett volna, de igazából akkor kezdett a dolog furcsa lenni, amikor a felkapcsolódás után ez az oldal fogadott a böngészőben:

A hibaüzenet szerint az oldalhoz tartozó SSL tanúsítvány “kicsit” hibás:

• Nem megbízható a kiállítója.
• Lejárt az érvényessége.
• Másik weboldalra szól.

Valójában csak akkor lehetne hibásabb, ha már vissza is vonták volna a tanúsítványt.

Aki mégis továbblép, az ezzel az oldallal találkozhat a bolognai reptéren:

Igazán eredeti dizájn. Oké, Bologna nem egy metropolisz, de a helyi egyetemen simán találhattak volna egy unatkozó diákot, aki egy hétvége alatt pofásabb weboldalt tud összedobni.

Ekkor már kíváncsi lettem és kis kísérletezéssel hamar kiderült, hogy a weboldalnak semmi köze ahhoz, hogy működik-e az internet hozzáférés, vagy sem.

Sok már itt a gyanús tényező:

• Tanúsítvány
• IP cím
• Dizájn
• Telefonszám gyűjtögetés

Ez volt az a pillanat, amikor konkrétan felálltam és körülnéztem, hátha ott ül valahol Troy Hunt az ő Pineapple-jével.

Egy rendes SSL tanúsítvány ezeket a kétségeimet könnyen eloszlathatta volna. De az ilyen, érvénytelen tanúsítvány semmire nem jó, mindössze annyit garantál, hogy az átlagfelhasználót idegesíteni fogja az oldal, a szakértőbb felhasználók pedig aggódni fognak az adataik biztonsága miatt. Aki HTTPS-re adja a fejét, csinálja rendesen, különben csak az ellenkezőjét éri el vele.

 

Technorati-címkék: SSL,security

JSON vagy nem JSON, ez itt a kérdés

Amikor egy REST API-hoz készítünk unit tesztet könnyen előfordulhat, hogy meg kell vizsgálnunk, hogy a szervertől kapott válasz olyan formában van-e, mint amiben kértük. Például egy stringről el kell döntenünk, vagy korrekt JSON-t tartalmaz-e.

Sok olyan megoldást lehet találni a neten, ami azt mondja, hogy elég, ha ellenőrizzük, hogy a kapott string < vagy { karakterrel kezdődik-e, hiszen a JavaScript Object Notation mindenképpen objektumokról vagy tömbökről szól. Ezzel a módszerrel nem csak az a baj, hogy egyetlen karakterből aligha tudjuk megmondani, hogy érvényes JSON stringről van-e szó, hanem az is, hogy érvényes lehet az a string is, ami nem tömböt vagy objektumot, hanem csak egy egyszerű értéket tartalmaz. Ami pedig a json.org szerint lehet:

A fapados karakter vizsgálgatás helyett szükségünk lenne egy korrektebb IsValidJson függvényre. Sajnos ilyet sehol nem találtam készen, de a Newtonsoft JSON.NET könyvtárral sikerült így megoldani a problémát:

try
{
    JToken.Parse(input);
    return true;
}
catch (JsonReaderException)
{
    return false;
}

Van jobb ötlete valakinek?

 

Technorati-címkék: JSON,WebAPI,test

IP szűrés Amazonban futó IIS-en

Az Amazon EC2 felhőjében nagyon egyszerűen hozhatunk létre terheléselosztott webszolgáltatásokat: csak felkattintunk két virtuális gépet, bekötjük őket a terheléselosztó mögé és már pöfögnek is vidáman. A sötét felhők akkor kezdenek gyülekezni az ember feje felett, amikor kiderül, hogy az IIS-ben beállított IP szűrés nem működik és a weboldalunkat bárki elérheti.

A gondot az okozza, hogy a virtuális gépeken futó IIS a terheléselosztót látja kliensként, nem pedig az eredeti böngészőt. (Annak az IP címére tökéletesen menne az IP szűrés, de arra pont nincs szükségünk.) Aki nem hiszi, nézzen utána az IIS naplófájljaiban.

Szerencsére az Amazon terheléselosztója támogatja a Proxy protokollt, aminek a lényege, hogy a valódi kliens IP címe az X-Forwarded-For HTTP fejléc mezőben továbbításra kerül. Az IIS alapból nem naplózza ennek a fejlécnek az értékét, de könnyen megkérhetjük rá:

További jó hír, hogy az IIS-t rávehetjük arra, hogy az X-Forwarded-For mező alapján végezzen IP szűrést. Ezt IIS 7 esetén a Dynamic IP Restriction modullal tudjuk megtenni, IIS 8-tól kezdve pedig az IP Address and Domain Restrictions modul része lett ez a funkció. Telepítés után nincs bekapcsolva, de egy kattintással aktiválhatjuk:

 

Technorati-címkék: Amazon,IIS,security