Marcus Olsson

Frilansande webbutvecklare

16 februari 2015 av Marcus Olsson

HTTPS med Cloudflares Flexible SSL

Nyligen så bestämde jag mig för att börja använda mig av HTTPS här på marcusolsson.me och stötte på ett litet frågetecken som jag antar att fler än jag någon gång kommer behöva tänka på.

Jag valde att använda mig av Cloudflares "Flexible SSL", vilket innebär att trafiken mellan webbläsaren och cloudflares servrar är kypterad – Cloudflare sitter i sin tur emellan min server och besökaren (läs mitt tidigare inlägg om Cloudflare om du vill veta mer om tjänsten) – min server använder sig alltså inte av ett eget utfärdat SSL-cerifikat.

'Cloudflare Flexible SSL'

Man kan lätt tro att för att använda sig av deras Flexible SSL så gör en standardkonfiguering i nginx, precis som om man använde ett vanligt SSL-certifikat eller Cloudflares "Full SSL":

server {
    listen 80;
    server_name marcusolsson.me;
    return 301 https://marcusolsson.me$request_uri;
}

server {
    listen 443 ssl;
    server_name marcusolsson.me;
    root /xxx/marcusolsson.me;
    [...]
}

Men icke, detta kommer att resultera i en redirect-loop som webbläsaren till slut avbryter.

'Chrome redirect loop' En redirect-loop i Google Chrome

Men varför? Jo – Cloudflares Flexible SSL lägger sig alltså endast mellan besökaren och Cloudflares servrar – trafiken till slutdestination (alltså ens egna server) kommer fortfarande att ske via port 80, inte standardporten för HTTPS; 443. Cloudflare kommer i sin tur (om alternativet är valt vill säga) alltid att erbjuda webbläsaren att ansluta via både HTTP och HTTPS.

Men hur tvingar man en HTTPS-anslutning då? Den enklaste metoden jag kunde hitta var följande:

server {
    listen 80;
    server_name marcusolsson.me;
    root /xxx/marcusolsson.me;
    
    if ($http_x_forwarded_proto = "http") {
        return 301 https://$server_name$request_uri;
    }

    [...]
}

Notera att endast ett server-block används.

Här kollar vi alltså om protokollet är HTTP, och om så är fallet så kör vi en 301:a till motsvarande HTTPS-sida.

För Apache så skulle en liknande metod kunna se ut som följande:

RewriteCond %{HTTP:CF-Visitor} !'"scheme":"http"'
RewriteRule ^(.*)$ https://marcusolsson.me$1 [L]

5 februari 2015 av Marcus Olsson

Att tänka på: Google AdSense, PII, och URL:er

webbjobb.io så är AdSense en betydande intäktskälla, därför var det mindre lustigt att se det här i ett mail från Google:

Dear Publisher,

It has come to our attention that you are passing personally identifiable information (PII) to Google through your use of one or more of Google's advertising products – DFP, AdSense, and/or DoubleClick AdExchange.

Our systems have detected information, including email addresses and/or passwords, being passed from the ad requests attached to this email.

[…]

We require that you fix the issue within 30 days.

Självklart en dundertabbe från min sida, då jag faktiskt har koll på vad som gäller; bifogat var även exempel på data som de flaggat:

Url sample: https://webbjobb.io/prenumerera/verifiera/redacted@example.com/xxxxxxxxxx

När jag byggde webbjobb.io så lade jag en del tid på att planera ut URL:erna, självklart vill man ha fina URL:er som direkt förklarar vad de gör utan att kännas "konstiga" för användaren, därför finns det sådana som:

webbjobb.io/prenumerera/verifiera/example@example.com/xxxxxxxxxx
webbjobb.io/prenumerera/installningar/example@example.com/xxxxxxxxxx
webbjobb.io/prenumerera/avsluta/example@example.com/xxxxxxxxxx

Där jag använde e-postadressen och en slumpmässig sträng på 10 tecken för att verifiera användaren.

Problemet med allt det här (vilket jag igen, borde ha tänkt på) är att Google läser av URL:en för att räkna ut vilka annonser som ska servas till användaren – och e-postadressen skickas då med i anropet. Google förbjuder en strikt att skicka med PII (Personal Identifiable Information) i annonsanropen.

För att lösa problemet var första tanken var så klart att bara ta bort annonserna på de sidorna det gällde, men jag ville inte riskera att fastna på något liknande igen – så jag fick bygga om systemet för att använda sig av GUIDs istället (och självklart vara bakåtkompatibelt). För PHP/Laravel så är det så enkelt som (exempelvis):

<?php
// via: http://stackoverflow.com/a/15875555/684195
public static function generateGUID() {

	$data = openssl_random_pseudo_bytes(16);

	assert(strlen($data) == 16);

	$data[6] = chr(ord($data[6]) & 0x0f | 0x40);
	$data[8] = chr(ord($data[8]) & 0x3f | 0x80);

	return vsprintf('%s%s-%s-%s-%s-%s%s%s', str_split(bin2hex($data), 4));
}

Fulare URL:er t.ex:

webbjobb.io/prenumerera/verifiera/xxxxxxxx-xxxx-4xxx-8xxx-xxxxxxxxxxxx

Men enligt Googles riktlinjer – och i slutändan säkrare för användarna.

5 februari 2015 av Marcus Olsson

Laravel 5 har anlänt

Det är nu snart 6 månader sedan utvecklingen av Laravel 4.3 drog igång, men ganska så snabbt insåg core-utvecklaren Tyler Otwell att det var en såpass stor uppdatering han ville genomföra att han helt enkelt valde att gå till version 5.0 i stället, samtidigt som han sköt på releasen på obestämd tid.

Men nu har Laravel 5.0 anlänt!

Väldigt mycket är nytt – för oss som har använt av oss av Laravel i ett par år nu är inte allt för vana med att se den här storleken av uppdateringar samtidigt, i många avseenden så är det som ett helt nytt ramverk man får se till att lära sig, med ny filstruktur, och helt nya sätt att hantera allt ifrån controllers, providers och vyerna.

Jag tänker inte täcka alla nyheter här då så många andra redan har gjort det bättre än vad jag kan göra det – kika t.ex. på det här inlägget från laravel-news, eller den här bloggserien från Matt Stauffer.

Laravel.com har även fått ett ansiktslyft (som vanligt då ramverket uppdateras).

Då är det inte så mycket mer än att börja läsa uppgraderingsguiden och sätta igång!

18 januari 2015 av Marcus Olsson

Laravel-tips del 3 – View composers

Ofta när man programmerar en applikation så stöter man förr eller senare på problemet att man har en variabel som man vill ska vara tillgänglig i alla vyer, eller kanske rentutav alla vyer som använder en särskild layout – något som man i Laravel inte löser särskilt bra med det vanliga hederliga with() i controllern, då variabeln endast blir tillgänglig i den aktuella vyn.

public function getIndex() {
	return View::make('public.frontpage')
	       ->with('title', 'startsida')
}

Man kan även så klart använda View::share(), som kommer att sätta variabeln i alla vyer (kanske genom att lägga till dem i BaseController?). Eller som somliga rekommenderar; att använda Laravels IoC-container för att sätta upp kod som kan registrera och "dela" på variabler.

Men, nu handlar det här om view composers.

View composers är en intressant och användbar funktion i Laravel som man kanske inte används jätteofta, trots att de kan vara otroligt användbart för att just sätta variabler i utvalda vyer.

Det enklaste sättet att använda en view composer är:

View::composer(array('*'), function($view) {
	$view->with('foo', 'bar');
});

Den här koden lägger man enklast in i en fil som alltid inkluderas (tips: skapa viewcomposers.php och dra med den i autoload-classmap i composer.json – eller kanske filters.php).

Det fina här är att du kan välja vyn (eller vyerna) som variabeln ska vara tillgänglig i, du behöver inte fundera på vilka routes eller vilken controller som ska använda dem.

Detta är enormt användbart om man är längre fram i utvecklingen av en applikation och man kommer på att man alltid behöver en variabel definerad, för att slippa skriva kod som:

@if(isset($foo) && $foo == 'bar')
	<p>Ett litet meddelande</p>
@endif

Men, tillbaka till fler exempel med composers. I exemplet ovan använder vi en asterisk, *, för att visa att variabeln ska vara tillgänglig för alla vyer. Man man kan på likadant vis ange specifika vyer:

View::composer(array('public.frontpage', 'public.login'), function($view) {
	$view->with('foo', 'bar');
});

Eller om man så önskar, en layout:

View::composer(array('layouts.main'), function($view) {
	$view->with('foo', 'bar');
});

Det blir ett litet annorlunda tänk, då man faktiskt jobbar med namnen på vy/blade-filerna istället för routes eller controllers som man vanligtvis gör i Laravel. Spana in dokumentationen för att läsa mer.

16 januari 2015 av Marcus Olsson

Vad är darodar.com och iloveitaly.co?

Om du använder dig av Google Analytics så har du säkert de senaste månaderna sett en hel del trafik under referrals ("hänvisningar") från bl.a. darodar.com och iloveitaly.co. Säkerligen rör det sig om dussintalet besök också som på mindre sajten kan fördärva statistiken. Varför då? Jo – detta rör sig inte om riktiga besökare alls.

'Darodar.com loveitaly.co'

Några klyftiga personer har kommit på att man kan skicka falsk data direkt till Google Analytics utan att behöva köra den Javascript-koden som man får från Google. De behöver bara gå igenom alla UA-id:n (ens unika id man får från Google, t.ex: UA-3150000-1) slumpmässigt. Detta utnyttjar de till att skicka data om spam-sidor – nyfikna sajtägare vill såklart spana in var ens trafik kommer fram, och så landar man på någon skräpsida eller referral-länk.

Besöken är alltså inte riktiga besök, utan endast falsk data.

Detta verkar fungera väldigt bra för spammarna, då jag i alla fall på mina sidor och de jag driftar åt mina kunder har märkt en markant uppgång i trafiken under januari – dessutom har det tillkommit en gäng liknande sidor.

Hur löser man det här problemet då?

Det finns dessvärre ingen jättebra lösning som åtgärdar alla spam-sidor samtidigt i nuläget, men om du upptäcker spam-sidor liknande darodar, iloveitaly och andra, då kan du för varje sida välja att blockera dem från att registreras i Google Analytics.

Logga in på Google Analytics, och gå igenom följande steg:

  1. Klicka på Admin (Administratör)
  2. Klicka på Property/Tracking Info (Webbegendom/Spårningsinformation)
  3. Klicka på Referral Exclusion List (Undantagslista för länk)
  4. Här kan du lägga till alla domänerna som inte önskar ska finnas med i din Google Analytics-traffik.

'Darodar.com loveitaly.co traffik'

I slutändan är det bara Google som kan göra någonting åt det här genom att ändra i sitt system så att spam av den här sorten inte kommer igenom och tillåts hos Google Analytics. När detta kan tänkas ske finns det i nuläget ingen som vet.

14 januari 2015 av Marcus Olsson

Google ger sig in i domänbranschen

Inte en direkt nyhet då Google Domains har haft en stängd beta under en längre tid – men nu har de även öppnat upp betan alla användare i USA, och presenterade en rad nya features för deras produkt.

  • Kopplingar till populära plattformar så som Shopify och Squarespace
  • Koppling till deras egna bloggverktyg Blogger
  • Flera nya domänändelser (.computer, .rentals, .gallery m.fl.)
  • Bättre DNS-hantering
  • Anonym registrering (för de toppdomänerna som tillåter det)

Det är spännande att se Google ge sig in i en bransch där de faktiskt ligger långt efter många konkurrenter, men domäner är onekligen något som har saknats i deras produktportfolio. Kan även tänka mig att de även kommer att erbjuda en förenklad/automatisk koppling till Google Apps inom en snar framtid – en produkt jag aldrig skulle klara mig utan.

Google Domains är en så länge stängd för svenska användare (man kommer åt tjänsten, men kan inte köpa/transfer domäner ännu), men om man så önskar kan man välja att bli kontaktad när de lanserar i Sverige.

Läs mer i Googles blogginlägg.

7 januari 2015 av Marcus Olsson

Nytt år, nya friska tag

Efter ett kort juluppehåll (första semestern på 18 månader!) så är 2015 äntligen här, med nya möjligheter och utmaningar.

Jag har ett par riktigt spännande projekt i pipeline:en som kommer att släppas under året. Vidare så kommer jag även att testa en rad olika nya saker (arbetsmetoder med mera) under året – beroende på hur de lyckas så är tanken att det kommer ett inlägg om detta med.

2015 är även året då Laravel (ramverket som används i en klar majoritet av mina projekt) kommer att få en ordentlig uppdatering i.o.m. 5.0 (tidigare 4.3), så tanken att lära sig andra språk och ramverk kommer att få skjutas upp lite framtill nya projekt hanteras effektivt med 5.0. Kan kanske låta som en mindre detalj – men kommer ändå att påverka en del hur jag jobbar och lägger upp min tid framöver.

Som vanligt, är du på jakt efter en webbutvecklare så är du varmt välkommen att kontakta mig – jag tar för tillfället emot nya små till medelstora projekt.

Vi hörs!

19 december  2014 av Marcus Olsson

God jul och gott nytt år!

God jul och gott nytt år!

God jul och gott nytt år önskar jag alla kunder och läsare som jag har haft under året!

Jag kommer att vara på julledighet från i dag (19 december) fram till den 7 januari, och kommer tyvärr endast ha möjlighet att sporadiskt svara på mail under den här tiden (läs mitt tidigare nyhetsbrev för mer information).

Ta väl hand om varandra, så hörs vi i januari igen!

11 december  2014 av Marcus Olsson

Årets mest lästa inlägg – 2014

Även i år är det dags att titta tillbaka på vad man egentligen har skrivit under året – och vad folk faktiskt läser. Publicerar "rapporten" någon vecka tidigare än vanligt då jag är på resande fot under jul och nyår.

I år steg antalet totala besök med runt 20%, detta till trots att jag byggde om URL-strukturen i mitten av året, vilket medförde att flera sidor föll hos Google under flera veckor.

Min "svit" är också fortfarande obruten, minst ett inlägg i månaden i nu 38 månader i sträck är jag uppe i (snittet ligger dock på fem inlägg i månaden under den perioden), något som jag är väldigt glad för.

Hur som, de mest lästa inläggen för 2014!

  1. Cloudflare, värt att använda?
    Mina tankar kring DNS/CDN-tjänsten Cloudflare, som jag använder till de flesta av mina projekt. Spoiler: DNS-delen är ovärderlig, var försiktig med CDN-bitarna.

  2. iPad tips – Läs pdf-filer i iBooks, utan iTunes
    "Klassiskt" inlägg ifrån 2010(!) som alltid har legat på topp bland de mest lästa artiklarna här på marcusolsson.me. Jag själv använder inte någon iPad längre (Xcodes simulator undanräknad), och är något tveksam till om innehållet fortfarande är aktuell.

  3. Frontendutvecklare eller front end-utvecklare?
    Ja, vad heter det egentligen?

  4. Stripe finns nu i Sverige (i β-form i alla fall)
    Det första inlägget från 2014 på listan, om när Stripe tillkännagav att de äntligen har öppnat upp sin beta i Sverige.

  5. Tummen upp för linnéuniversitetet
    Inför varje terminsstart kommer det en hel del folk och läser min text om webbprogrammeringsprogrammet vid LNU. Får även ett par mail om året som jag givetvis gärna svarar på.

  6. Sätt upp din utvecklingsmiljö för PHP-utveckling med Homebrew
    Snabbguide till att komma igång med *AMP-stacken med hjälp av Homebrew i MacOS X.

  7. Dela inlägg på Twitter och Facebook – utan att använda plugins eller bibliotek
    Kodexempel på hur man enklare kan skapa "dela"-knappar för Twitter och Facebook utan att använda sig av några plugins.

  8. Snabbstarta ditt projekt med Flight, php-activerecord och Twig
    Ännu mer kodexempel, här om hur man kan koppla ihop micro-ramverket "Flight-PHP" med phpActiverecord och Twig för att bygga små till medelstora applikationer. Något som jag fortfarande använder som bas till många projekt.

  9. Säkerhet på nätet – en liten lathund
    Tidigare i år efter en rad uppseendeväckande dataintrång skrev jag om ett par enkla grundregler för hur man kan skydda sig på internet.

  10. Främlingsfientliga avslöjas via hashningen hos Disqus
    Fjolårets överlägset mest lästa inlägg, där jag skrev om hur Researchgruppen förmodligen gick tillväga när du avslöjande en rad rasistiska utalanden från flera SD-politiker.

Kanske värt att nämna är också att min projektsida har ökat antalet besökare med över 500% i år, min kontaktsida är inte långt därifrån. Detta hör sannolikt i hop med att jag numera kör mitt egna race som frilansande webbutvecklare.

9 december  2014 av Marcus Olsson

Google gör om reCaptcha

Här kommer en trevlig nyhet för oss som inte är särskilt förtjusta i det flera år gamla öppna captcha systemet som Google har tillhandahållit för att förebygga och förhindra SPAM:

Googles gamla reCaptcha

Google kommer nu att göra en ordentlig översyn och uppdatering av systemet, vilket innebär att man inte kommer att behöva göra så mycket mer än att klicka i en checkbox.

Googles nya reCaptcha

Hur går det här till då? Om du som de allra flesta internetanvändarna använder någon av Googles tjänster så som deras sökmotor, Gmail och/eller andra produkter, så lagras en enkel cookie på din datorn som talar om hur du har använt dem. De kan sedan använda den här datan för att dra slutsatser kring om du är en människa eller inte.

Det nya Captcha-systemet använder även en rad andra parametrar, t.ex. rörelsemönstret på muspekaren för att förbättra resultatet.

För att skydda webbplatserna så kan man fortfarande bli tillfrågad att fylla i en "klassisk" captcha om systemet är osäker; men även här har de gjort ändringar för mobilanvändare:

Google kitten reCaptcha

Läs mer om systemet på Googles "Webmaster Central Blog".

25 november 2014 av Marcus Olsson

Äger du inte ditt egna namn på webben? Nu finns det inga ursäkter längre

.SE (Stiftelsen för internetinfrastruktur) har just nu en kampanj där man gratis kan registrera sitt egna namn som en .se-domän helt gratis under ett år (därefter så kostar det ca. 100kr/år). Det finns inga som helst ursäkter till att inte göra detta (om du inte redan har vill säga).

Med ditt egna domännamn kan du enklare styra bilden av dig själv på nätet när någon googlar ditt namn – se det som en enkel (och nu alltså gratis) chans att marknadsföra dig själv, något som kan vara ovärderligt längre fram.

Har du ett vanligt namn, och motsvarande domän är ledig – grattis! Då är det bara att plocka upp den så snart du kan, i morgon kan den vara borta, och du är då i en sämre position att göra dig själv synbar.

För er med ett mer ovanligt namn, då är ert egna domännamn en billig försäkring om t.ex. någonting mindre smikrande skulle dyka upp om er i sökresultaten. Dessutom så har ni större chans att råka ut för s.k. domänpirater – någon annan som tar ert namn för att sedan antingen sälja tillbaka det dyrt, eller för att använda domänen för att sprida falska uppgifter, och för att sedan ta betalt för att plocka bort dem.

Kampanjen hittar du just på domanpirater.se.