Vi er nå godt i gang med det “nye” året, år 2009. Som en kort oppsummering av hvordan året har startet så bare så kan det nevnes at det ikke var noe fyrverkeri i Barcelona, men jeg vet jo hvor alt fyrverkeriet ble av… smuglet inn av leketøyopprørere som tror de kan befri midtøsten og gjøre Gazastripen til et himmelrike hvor pene jenter i rosa kjoler spretter rundt i sakte film. Ok, nok politikk.

Jeg tittet litt på eldre bloggposter jeg har skrevet, og skremmende nok så har dette året startet ganske så likt for meg som 2008 gjorde. For i dag har jeg vært hjemme med forkjølelse og hatt drømmer om rare ting som brukerhåndtering i LDAP og Bifrost. For på jobben arbeider jeg med videreutvikling av nettopp Bifrost, en follow-me utskriftsløsning basert på åpen kildekode, et spennende prosjekt som jeg var med på å starte på i slutten av 2007. Men, rare drømmer er vel sikkert bare helt normalt for IT-folk…

Barcelona
Som jeg så vidt nevnte over, så var jeg i Barcelona på nyttårsaften, og jeg lærte mye nytt, ihvertfall noe. For det første, det er lov å ta med seg medbrakt vin og nyte den nede i baren på hotellet. Det virket nesten som at det var en selvfølge at jeg kunne gjøre noe slikt. Bartenderen åpnet gjerne vinen for meg også. Og jeg som stresset rundt i et par dager for å lete etter en vinopptrekker…

Om du har planer om å se den store og berømte kirken Sagrada Família så bør du ha god tid, spesielt om du har tenkt deg inn i den. Alle vil se den store kirken som aldri blir ferdig, selv på nyttårsaften. Køen gikk rundt hjørnet, den var lenger enn hva jeg klarte å tenke på. Det nærmeste jeg kom var et bilde.

Et tips fra en klok mann, hvis du noen gang skal til Barcelona på nyttårsaften, ikke drøy for lenge før du drar ut med drosje ut på byen. Etter kl 19 er det helt umulig å ringe drosje. Vi var heldige, det var sikkert sjarmen, for vi klarte å praje to drosjer som var off duty mens vi febrilsk røra rundt i forsøk på å finne undergrunnsbanen.

Det var riktignok ikke noe fyrverkeri i Barcelona, men nyttårsaften ble en trivelig kveld fordet. Vi var en liten vennegjeng som dro dit for fire dager, for å oppleve byen og få en annerledes nyttårsfeiring. Det ble mye gåing i løpet av ferien, opp og ned gater og fram og tilbake gjennom et kjøpesenter, men det er vel slik det skal være på ferie. Man skal være mer sliten etterpå enn man var før…

Oppdatering 12.01.2015
Mens jeg ryddet litt, så fant jeg faktisk kvitteringen fra restauranten hvor vi spiste den nyttårsaften, og den heter Meson David.
Den har visst helt grei rating på Tripadvisor.

I dag ble jeg tatt med ut på en liten tur i skogen, opp til Røysjø. Vel, nesten. Vi snudde litt tidligere enn planlagt på grunn av snøen.

På vei tilbake passerte vi et elveløp som renner ut fra Langevann. Sola lå perfekt og det var fram med kameraet.

Bildene er tatt med kameraet på en Sony Ericsson P1i mobiltelefon, kl 11:50 den 30. november. Jeg stilte hvitbalansen til “Overskyet”, da automagikken ikke fungerte optimalt.

I en samtale med en god venn kom vi inn på forskjellene mellom en tekniker og en økonom. De tenker, ikke så veldig overraskende, svært forskjellig.

– Knut-Olav: min matte begrenser seg til 0 og 1
– Steffen: Hehe, 0 og 1. Jeg driver bare med kvasimatte.. h for tallfestet humankapital og u for fagforeningers innflytelse
– Knut-Olav: “Det mest usympatiske ved datamaskiner er at de bare kan si ja eller nei, ikke kanskje.” (sitat Birgitte Bardot)
– Steffen: Hehe. hadde økonomer skapt datamaskinen kunne den hverken ha sagt ja eller nei, men bare kanskje

I told you so…?

I mulighetenes land USA går det meste an. Ikke ta meg feil, jeg tror Obama kan ha en positiv innvirkning på USA, både som et land og for resten av verden.

Men de har fortsatt ikke hatt en kvinnelig president. Jeg minnes Bruntland som en god statsminister. Kan USA få en kvinnelig president? Jeg mener Hillary kanskje var moden nok, men kanskje det skjer i 2016? Hvem vet

Første dag med snø høsten 2008

Oracle Weblogic (former BEA Weblogic) enforces a security model by default that is unhealthy for developers writing REST web services or other kinds of web applications using HTTP Authentication for security.

By default, when sending an HTTP Authentication header, Weblogic will check its own security realms for users matching the username and password. If there is no match, a 401 UNAUTHORIZED response is sent directly back to the client, without ever hitting your web application code. That takes care of the security, i guess…

This might sound like a good idea, except for those cases when your application is able to handle its own authentication. How can your application handle security when the request never hits your code?

Another problem, as i see it, is that Weblogic enforces this security model even for web application that are configured with no security at all. You can use your web application as much as you like, as long as you don’t send any HTTP Authentication headers. But when you decide to send an HTTP Authentication header like that, just for fun or when navigating from another website after being authenticated, Weblogic decides on your applications behalf that you are no longer worthy enough to use your application. That sucks…

The solution
The solution? Yes, you can bypass the security model of Weblogic, at least for those applications that does not rely on the web containers security. It took me many weeks of frustration before I found a solution to my problem, but I got there…

Shutdown your admin server and open the config/config.xml file for editing. Add the following XML code into the <security -configuration> node:

<enforce-valid-basic-auth-credentials>
    false
</enforce-valid-basic-auth-credentials>

Start the admin server again. Then you need to restart all the application servers to make the change take effect. Restart them one by one to avoid downtime… you are of course running a cluster right?

Har du glemt passordet ditt på værvarslingstjenesten eller har hatt problemer med å registrere nye værvarslinger i det siste? Nye fikser er ute.

Nå er det mulig for å sette et nytt passord på kontoen din dersom du har glemt det. Måten du går frem på er å forsøke å logge inn med tomt passord, så vil du se en lenke som fører deg videre til prosessen for å sette nytt passord.

Det har også vært problemer med å registrere nye værvarslinger, som skyldtes manglende adresse i HTML-skjemaet på forsiden. Dette er nå rettet.

Så, prøv gjerne igjen

Det er fredag kveld, jeg sitter hos en kamerat og progger litt Perl. Så begynte vi å titte litt på hvilke Firefox plugins vi kjørte og fant ut at vi begge hadde Firebug, Web Developer og Download Statusbar. Videre har jeg også en Firefox plugin som heter XSS Me.

Da bestemte jeg meg for å teste Perl-applikasjonen min for sikkerhetshull. Denne applikasjonen er svært enkel. Den har ett HTML-skjema med ett input-felt, og data fra dette feltet blir listet ut på forsiden. “Shout” heter det, enkelt og greit. Jeg fyrte avgårde alle testene i XSS Me mot dette skjemaet og fikk ørten sikkerhetsvarslinger i retur. Dette løste jeg riktignok med en enkel pipe igjennom html-filteret til Template Toolkit.

Vi utforsket dette videre. Kameraten min smalt opp et lite PHP-script som tok innholdet fra et textarea-felt og viste det uendret ut på HTML-sida. Vi fant fort ut at PHP gjorde noe magisk bak scenen, som PHP så gjerne ofte gjør; magic quotes heter det. Men jeg lurte jæveln…


<script>
 window.location=String.fromCharCode(104)
  + String.fromCharCode(116)
  + String.fromCharCode(116)
  + String.fromCharCode(112)
  + String.fromCharCode(58)
  + String.fromCharCode(47)
  + String.fromCharCode(47)
  + String.fromCharCode(103)
  + String.fromCharCode(111)
  + String.fromCharCode(111)
  + String.fromCharCode(103)
  + String.fromCharCode(108)
  + String.fromCharCode(101)
  + String.fromCharCode(46)
  + String.fromCharCode(99)
  + String.fromCharCode(111)
  + String.fromCharCode(109);
</script>


Denne koden dekoder tallene til tegn, setter dem sammen til en tekststreng, tilordner tekststrengen til “document.location”. Javascriptet sender deg så videre til en ny nettside, rett og slett til http://google.com.

Ironisk nok klarte jeg å redirecte meg selv til google da jeg skulle ta en titt på preview’n på dette innlegget. Glemte visst å enkode HTML-taggene, tenke seg det…

Håndtering av brukere kan bli en tung prosess dersom du har flere websider i drift. Ofte må brukere logge inn flere ganger for å benytte seg av disse tjenestene, og kanskje har du tjenestene dine spredt ut over flere domener, noe som gjør det umulig å bruke cookies for å verifisere at brukeren faktisk er logge inn. Her beskriverer jeg en single-sign-on-løsning (SSO) som vil på tvers av alle webløsningene du måtte ha, gjøre at din bedrift vil få et sømløst ansikt utad. I tillegg skal vi tillate autentisering av brukere med OpenID.

Vi ønsker at alle brukere av våre tjenester skal registreres i en sentral brukerdatabase. Vi ønsker derimot ikke å lage store endringer i eksisterende løsninger, spesielt ikke “hyllevare”-produkter. Mange hyllevareprodukter har allerede støtte for OpenID, men det kan vi ikke bruke uten endringer. Da mister vi oversikt over hvor mange brukere vi har, brukerne får ingen sentral profil på tvers av systemene og de må skrive inn sin OpenID-adresse og trykke “Logg inn med OpenID” på alle systemene våres. Derfor har vi behov for en tilpasset utgave av OpenID som fungerer innenfor vårt domene av webløsninger.

Først er det viktig å skille mellom vår løsning for SSO mellom egne tjenester og OpenID for SSO mellom eksterne tjenester. Vi trenger begge til å fungere sammen. I vår SSO-løsning ønsker vi ikke at brukeren skal måtte skrive inn sitt brukernavn på alle systemene. Fordi noen av systemene ligger på separate domener og ikke kan dele cookies blir vi nødt til å ha “Logg inn”-knapper på alle systemene, selv om brukeren allerede er logget inn.

Eksempelet
Vi gjør et eksempel ved at en bruker skal logge inn på et forum. Ved å trykke på “Logg inn” blir man sendt til en sentral side hvor man kan registrere seg eller logge inn. Vi kaller denne for profiltjenesten. Med denne linken sendes også en URL som viser hvor brukeren kom fra. Når brukeren er registrert, verifisert (med enten e-post eller SMS) og logget inn blir brukeren sendt tilbake til foumet, der han klikket “Logg inn”. URL-en som brukeren sendes tilbake til inneholder nå også en parameter med brukernavnet sitt samt et token som vi skal bruke for å kontrollere at brukeren faktisk er innlogget. Det som skjer så er at forumet henter profildata fra profiltjenesten for å fylle ut navn, e-post og andre profildata som forumet har behov for. Dette er en funksjonalitet som finnes i OpenID-løsninger.

Dette gir oss en tre-veis autentisering. Brukeren stoler på oss (ja, ikke sant…) eller sin OpenID-tilbyder, profilsiden vår vet at det er riktig bruker som har logget inn og forumet stoler på profilsiden vår og kan verifisere at brukerens token er korrekt.

To samspillende løsninger
Så, hva gjør vår SSO-løsning forskjellig fra OpenID? Ikke så mye, men ganske forskjellig for det, fra brukerens ståsted. For det første er det intet felt for å skrive inn sitt OpenID-navn i våre systemer, heller ikke noe brukernavn- og passord-felter. Det er bare en “Logg inn”-knapp. Denne knappen fører til vår profil- og innloggingsside, ikke til brukerens OpenID-tilbyder. Her logger brukeren inn, enten med en OpenID-konto fra et eller annet sted i verden eller et brukernavn og passord mot vår egen brukerdatabase. Dette betyr at forumet som brukeren opprinnelig prøvde å logge inn på ikke vet brukernavnet til brukeren, faktisk ingenting om brukeren. Derfor må profilsiden vår fortelle forumet hvilken bruker som faktisk har logget inn, når brukeren sendes tilbake.

Da jeg sa at vår SSO-løsning og OpenID må holdes klart adskilt så mente jeg det. Våre systemer har ikke OpenID, da de ikke godtar innlogging fra OpenID-tilbydere. De godtar kun innlogging via vår profilside. Allikevel er det en OpenID-løsning, men en tilpasset OpenID-løsning, og alt som minner om OpenID for sluttbrukere er strippet bort. Det er egentlig ikke lenger OpenID lenger.

OpenID
Så hva med OpenID? Profilsiden støtter OpenID. Brukere trenger ikke å lagre noe passord i vår brukerdatabase. De logger inn via sin OpenID-tilbyder, og oppretter så en profilkonto hos oss med navn, telefonnummer, epost og what-not som vi kan ha behov for. Vi kan godt kreve aktivering av profilen ved å sende dem en kode på SMS eller epost, slik at vi får en viss kontroll over brukerne våre og vite at det er levende personer som står bak profilene. Når brukerne er logget inn på profilsiden vår har de logget inn som på en hvilken som helst annen OpenID-støttet nettside på Internett. Når brukerne så går til de andre systemene våre vil de autentiseres mot vår profilside, på samme måte som OpenID fungerer.

Nyhet! Få en RSS-feed med tredagers værvarsel rett til din mobiltelefon.

Det hele er svært enkelt. Skriv inn sted eller dra deg fram på kartet til stedet du ønsker værvarsel fra og vips, så får du en URL du kan skrive inn i RSS-leseren på telefonen din. Feedene kan selvsagt også vises i andre RSS-lesere, som for eksempel på en Squeezebox.

Dersom du er registrert og logget inn vil søkene dine lagres og du får en enklere URL for hvert av dine søk. I tillegg vil stedsnavnet vises i tittelen på feeden slik at du enkelt kan se forskjell dersom du har registrert flere feeds.