Etikettarkiv: https

Google favoriserar https

Som Google meddelade för några månader sedan gällande att de avser att favorisera webbsajter som använder sig av https är nu officiellt bekräftat.

Detta är så klart en bra utveckling men många webbhotell åtminstone i Sverige verkar inte riktigt vara med på banan.

För att citera några webbhotell:

”För att ha SSL-certifikat under eget domännamn krävs en egen IP-adress” – Loopia

”Ett SSL-cert med inkluderad privat ipv4-adress” – Binero

Det behövs ej egen IP-adress utan Server Name Indication (SNI) finns implementerat i TLS (SSL) och bör användas istället. Som alla vet så är IP-adresserna slut sedan länge och att slösa på detta sätt gynnar ingen som webbhotellen föreslår.

Att kräva privat IP-adress för tls är lite 1900-tal tycker jag, eller i varje fall före 2010. Vid 2010 påstår jag tåget gick.

Skriver Internetgurun Patrik Fältström i gruppen Kodapor på Facebook.

Det finns även en mängd andra saker som bör tänkas på (lämna gärna en kommentar om jag glömt något mer)

  • Använd protokollrelativa URL:er dvs // istället för http://domän (finns i RFC 1808 sedan 16 år tillbaka)
  • Testa så du får bra betyg via Qualys SSL-Test
  • Håll koll på när certifikatet förfaller
  • Hur gör du revokering om något inträffar såsom Heartbleed?
  • Använd PFS, secure cookies och HSTS.
  • Vilket certifikat ska användas? Domänvaliderat eller EV? Wildcard?
  • Kontollera så du ej har mixed content:

Mixed content

Lättaste sättet att hitta mixed-content är enligt mig att använda Chrome Developer Tools och klicka på Networks-tabben.

Och jag säljer så klart SSL-Certifikat via https.se.

Google Adsense nu med https-stöd

Google har nu lagt in stöd för https-sajter för de som använder Google Adsense. Rätt minimal förändring som behövs göras för att visa koden:

<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js">
</script>

Denna kodsnutt gäller så klart om du använder asynkron annonskod, vilket jag hoppas att du gör. Denna förändring gör bl.a. att eventuella felmeddelanden i webbläsaren såsom nedan försvinner om du visar annonser på en https-sajt:

https varning

Att lämna ute http eller https i sökvägen och i stället börja med två slash \\ kallas för protokoll-relativa URL:er och är ett bra sätt att ej erhålla en mixad http/https-sida av misstag.

PS: Använd rabattkoden UTVBLG för 100 kr rabatt på SSL-certifikat via min tjänst https.se

Källa: Google

Apple iPhone/iPad och Remote Virtual Interfaces

Jag har tidigare skrivit om hur du analyserar iPhone och iPad-appars nyttjande av API:er med hjälp av Charles Proxy. Dock så när jag testade en App nyligen så sket den högaktningsfullt i mina proxy-inställningar. Det man då kan göra är att använda något som heter Remote Virtual Interfaces (RVI).

Att använda RVI kräver en Mac med kommandot rvictl. Det enda du behöver göra är att skriva in följande kommando från kommandotolken med iPhone eller iPad ansluten via USB-kabeln:

$ rvictl -s 91f2312af0624dade4731e934d3962e45dda0833

Där den långa strängen ska vara din UDID eller identifier som det heter i Xcode Organizer. Du kan även hitta UDID genom att klicka på enhetens serienummer i iTunes.

När kommandot genomförts så skapas en ny virtuell enhet vid namn rvi0 enligt följande:

$ ifconfig rvi0
rvi0: flags=3005<UP,DEBUG,LINK0,LINK1> mtu 0

Sen är det bara att använda Wireshark eller tcpdump för att lagra och titta på kommunikation till och från telefonen. Skillnaden mot att exempelvis använda Charles är att du ej ser krypterad https-trafik.

Exempel på hela förfarandet:

Klicka på bilden för en större version.

Uppdatering: Glömde att skriva att Apple även har en supportsida för ”Getting a Packet Trace”.

Så analyserar och använder du iPhone Appars API

Visste du att majoriteten av alla iPhone och iPad-appar använder någon form av API?

Jag tänkte gå igenom hur du själv kan använda dessa API:er i dina egna implementationer med hjälp av exempelvis PHP eller Python. Observera att informationen som du hämtar via API:er eventuellt inte användas till vad som helst då den kan omfattas av upphovsrätt eller andra lagar.

Först och främst så måste vi ladda hem någon form av Proxy-programmvara som medger analys av den API-trafik som går fram och tillbaka från iPhonen och Appen. Jag rekommenderar Charles Proxy som är gratis att använda men det finns även en betalversion för ynka 50$ som jag har köpt (du slipper ”nag-screens” och sådant). Charles Proxy fungerar för Linux, Mac och Windows.

Här är en skärmdump på hur det ser ut när du startat upp Charles Proxy:

Så, det första vi ska göra är att stänga av så att vi ej ser all webbsurf till och från vår egna dator och det kan man göra under Proyx-fliken och sedan se till att ”Windows Proxy” ej är förkryssad.

Nästa steg är att vi ska skicka ett E-brev med Charles SSL-certifikat till vår iPhone för att ges möjlighet att analysera krypterad HTTPS-trafik till och från telefonen. Ladda hem följande ZIP-fil: charlesproxy.com/ssl.zip och packa upp den där du sedan hittar en .CRT fil som du bifogar i ett mail som du sedan kan öppna på din iPhone (Dropbox eller annan typ av filöverföring går säkert också bra).

När du lagt in Charles certifikat i din telefon bör det se ut så här under Inställningar -> Allmän -> Profil (längst ner):

Då var det nästa steg, och det är att ta reda på IP-adressen till din dator. Jag brukar använda cmd.exe och sedan skriva ipconfig så bör det se ut något i stil med:

Denna IP-adress skall vi ange under inställningarna som det nätverk vår iPhone är ansluten till. I mitt fall så är det via WiFi och längst ner under inställningarna för det trådlösa nätverket anger jag IP-adressen till min dator som kör Charles Proxy så det ser ut så här:

Sedan är det bara att starta den App som vi vill analysera på iPhonen, i mitt fall så startar jag Swedavias App vid namn Arlanda flygplats. Och se hur Charles Proxy visar API-anropen efter varandra. Eftersom vi är intresserad av Avångar så klickar jag helt enkelt på Avångar i Arlanda Appen och får upp följande intressanta API-anrop i Charles:

Fleratalet parametrar är intressanta att anteckna eftersom de behövs vid anrop från PHP eller Python. Det varierar från app till app men i detta fall är det URL:en för anrop som innehåller flygplats (airport=arn_utr) samt datum (searchDate=2011-08-10).

Tittar vi på XML-svaret så ser det ut enligt följande:

När vi sedan implementerat en funktion som härmar denna förfrågan så bör vi få ut samma XML-svar i slutändan och kan då exempelvis hämta hem avgångar med PHP och CURL på följande sätt:

<?php
  $today = date("Y-m-d");
  $path = '/ArrivalsDeparturesMobile/ArrDepMobileService/ArrDep.asmx/GetDeparturesFlightTable?airport=arn_utr&language=sv&searchString=&searchDate='.$today;
  $host = "wsc1.swedavia.se";

  $headers = array(
    "GET $path HTTP/1.1",
    "Host: $host",
    "User-Agent: Arlanda/1.4 CFNetwork/485.13.9 Darwin/11.0.0",
    "Authorization: Basic V1NBcnJEZXBNb2JpbGU6c1AtR0U1NWJlY3I4c1BhKWhlMHBlNXJ1NkVmYUNyRSE=",
    "Accept: */*",
    "Accept-Language: sv-se",
    "Accept-Encoding: gzip, deflate",
    "Pragma: no-cache",
    "Connection: keep-alive"
  );

  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL, "http://".$host.$path);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
  curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

  $sXML = curl_exec($ch);

  $oXML = new SimpleXMLElement($sXML);

  print_r($oXML);

?>

Ovan kod kan du sedan köra från kommandotolken enligt följande:

$ php swedavia.php

Tadaa! Nu slipper vi använda vår iPhone varje gång vi ska se avgångar från Arlanda. I detta exempel så behövdes ej SSL-certifikatet användas då anropen skickas i klartext.

Google +1

Nu har jag installerat Googles senaste +1-knapp här på bloggen som skall synas vid varje blogginlägg längst uppe till höger. När någon som du är vän med använder knappen så kommer detta att synas i sökresultatet. Ungefär som delade länkar från Twitter, Facebook och Google Reader(?) som dyker  i sökresultatet.

De sajter du plussar på synes även på din Google Profil samt så kommer annonser att anpassas efter den typ av sajter som du plussar på. Här finns sekretesspolicyn för Google Plus One.

”Rekommendationer när du vill ha dem.”

Vad händer då över nätverket när man trycker på knappen? Jo ett JSON RPC anrop görs till ungefär följande URL med hjälp av HTTP POST:

https://clients6.google.com/rpc?key=AIzaSyCKSbrvDasunBoV16zDH9R33D88CeLr9DF

Följande skickas från klienten:

[{”method”:”pos.plusones.insert”,”id”:”pos.plusones.insert”,”params”:{”cdx”:”154211″,”id”:”http://techcrunch.com/2011/03/30/google-plus-one/”,”source”:”widget”,”container”:”http://techcrunch.com/2011/03/30/google-plus-one/”,”userId”:”@viewer”,”groupId”:”@self”},”jsonrpc”:”2.0″,”key”:”pos.plusones.insert”,”apiVersion”:”v1″}]

Och svaret från Google är enligt följande:

[
{
”result”: {
”kind”: ”pos#plusones”,
”id”: ”http://techcrunch.com/2011/03/30/google-plus-one/”,
”isSetByViewer”: true,
”metadata”: {
”type”: ”URL”,
”title”: ” With +1, Google Search Goes Truly Social — As Do Google Ads ”,
”globalCounts”: {
”count”: 0.0
}
}
},
”id”: ”pos.plusones.insert”
}
]
Ovan förfrågan går alltså krypterat över https och det enda som är unikt är troligtvis key=X. Undrar om det är möjligt att göra en egen knapp?

Här kan du generera HTML-kod för knappen eller så kan du ladda hem ett WordPress-plugin här.

Andra som bloggat om detta: Nikke, Magnus, Kristoffer.

SSL-certifikat från https.se

SSL-Certifikat

Sedan en tid tillbaka så äger jag domännamnet https.se där jag säljer SSL-certifikat för att använda till https:// sajter. Beställningssystemet finslipas dagligen och snart är förhoppningsvis majoriteten av alla buggar åtgärdade.

Vill du erhålla 200kr rabatt vid beställning av valfritt certifikat? Använd då följande rabattkod: UTVB91

Eller följande direktlänk: https.se/coupon.php?kod=UTVB91

Om du är bloggare och vill erbjuda dina bloggläsare rabatt eller erhålla ett gratis SSL-certifikat att lotta ut, hör av dig till mig.

10 saker att tänka på vid skapande av API

Så du går i tankarna på att tillhandahålla ett API? Då har du kommit rätt. Jag försöker här att redogöra över de tankar jag har när det gäller det mesta vid API utveckling.

Först och främst så bör du ställa dig frågan om ett API verkligen är rätt, och i de flesta fall så skulle jag säga att API är rätt väg. De fall då ett API kanske inte är lämpligt är då din tjänst enbart bygger på ett annat API och ej tillför något mervärde. Prioritering är också en viktig punkt, i flertalet fall så kan det tillåmed vara så att ett API skall finnas innan en webbsida finnes (framförallt i offentlig sektor).

Om du tillhandahåller en iPhone-app eller någon annan typ av extern tjänst så är detta också tillämpningsbart.

1. Placera ditt API under ett eget DNS-namn, exempelvis api.domän.se. Även om api.domän.se pekar till domän.se till en början.

2. Detta har med ovan punkt att göra: Exportera din data till en separat server som exempelvis ligger i molnet. Detta för att enkelt göra ditt API redundant och icke beroende av din ordinarie tjänst som kanske får problem om du får tusentals API-förfrågningar per sekund. Kan dock bli problem med realtidstjänster om API:et tillhandahåller sekundaktuell information.

3. Fundera om du bör tillhandahålla en krypterad version över HTTPS. Fundera även över om anrop bör vara signerade, för https i sitt standardutförande verifierar ej klient, bara server. Självklart kan du köpa SSL-certifikat via min sajt https.se.

4. Vilket format är lämpligast. JSON REST, XML SOAP eller annat? Jag rekommenderar REST JSON. Se Google eller FRAPI

5. Vill du hålla koll på vilka som anropar ditt API? Då bör du tillhandahålla en API-nyckel och bygga en registreringsprocess för detta. Enklast är att använda Google Forms. Det finns ofantligt många sätt att bygga detta förfarande.

6. Du bör införa kontroll av anrop samt begränsningar. Detta kan vara bra för att förhindra miljontals anrop i sekunden eller forcering av lösenord/användarnamn. Begränsa förfrågningar på så mycket som du bara kan, exempelvis IP-nummer.

7. Vilken licens kan användas? Här kan myndigheter få problem då CC-licenser kan gå emot lagstiftning. E-delegationen håller på med ett arbete om bl.a. detta och kommer att tillhandahålla mer information.

8. Upprätta en changelog, blogg eller E-postlista (Google Groups) för att berätta om eventuella förändringar. Här kan det även vara bra att prefixa alla API-anrop med versionsnummer för att bibehålla bakåtkompabilitet. Exempelvis: api.domän.se/v1/anropstyp

9. Glöm framförallt inte att erbjuda dokumentation och kod-exempel på hur API:et används. Berätta om innehållet, begränsningar, datatyper, relationer, statuskoder osv. Kanske ett forum för frågor? Wiki? Status-sida för att berätta om eventuella problem med ditt API eller fördröjningar. Se Pingdom eller Watchmouse.

10. Övriga punkter: Länka till de som använder ditt API för att uppmuntra användning. Ta betalt för ditt API? Berätta för Mashup.se att du har ett API. Hur länge bör du cacha? Pagination, page=1 vs.  cursor: start_id=1234. Loggning? If-Modified-Since header?

That’s it! Har säkert glömt många bra saker, skriv en kommentar och berätta vad du saknar.

Gratis affärsidé: Svenskt CDN

Ett CDN står för Content Delivery Network och jag har även bloggat om hur ett CDN kan avlasta din webbsajt här. Dock så saknar jag en svensk CDN-leverantör där jag lätt kan lägga upp tusentals filer och få dessa automatiskt utspridda till åtskilliga operatörer och geografiska placeringar i Sverige till en låg kostnad.

Hur ska denna affärsidé genomföras rent tekniskt då? Hyr Co-Location  hos ett antal Internetoperatörer och skapa en infrastruktur som automatiskt uppdateras när filer laddas upp. Skapa även ett lättanvänt webbgränssnitt som möjliggör uppladdning enkelt via FTP/https/SFTP.

Här hittar du fler av mina affärsidéer: utvbloggen.se/affarsideer

Du hittar även fler gratis affärsidéer hos Christian och Peter som bloggar på Disruptive.nu