Django 1.2.5 release notes

Välkommen till Django 1.2.5!

Detta är den femte ”bugfix”-releasen i Django 1.2-serien, som förbättrar stabiliteten och prestandan i Django 1.2-kodbasen.

Med fyra undantag är Django 1.2.5 bakåtkompatibel med Django 1.2.4. Den innehåller också ett antal korrigeringar och andra förbättringar. Django 1.2.5 är en rekommenderad uppgradering för all utveckling eller distribution som för närvarande använder eller riktar in sig på Django 1.2.

För fullständig information om nya funktioner, inkompatibilitet bakåt och utdaterade funktioner i 1.2-grenen, se Django 1.2 release notes.

Bakåtkompatibla förändringar

CSRF-undantag för AJAX-förfrågningar

Django innehåller en CSRF-skyddsmekanism som använder sig av en token som infogas i utgående formulär. Middleware kontrollerar sedan att token finns när formuläret skickas in och validerar det.

Före Django 1.2.5 gjorde vårt CSRF-skydd ett undantag för AJAX-förfrågningar, på följande grunder:

• Många AJAX-verktyg lägger till en X-Requested-With-header när XMLHttpRequest används.

• Webbläsare har strikta policyer för samma ursprung när det gäller XMLHttpRequest.

• I en webbläsare är XMLHttpRequest det enda sättet att lägga till en anpassad header av det här slaget.

För att underlätta användningen tillämpade vi därför inte CSRF-kontroller på förfrågningar som verkade vara AJAX på grundval av X-Requested-With-headern. Webbramverket Ruby on Rails hade ett liknande undantag.

Nyligen gjorde ingenjörer på Google medlemmar i Ruby on Rails-utvecklingsteamet uppmärksamma på en kombination av webbläsarplugins och omdirigeringar som kan göra det möjligt för en angripare att tillhandahålla anpassade HTTP-rubriker på en begäran till vilken webbplats som helst. Detta kan göra det möjligt för en förfalskad begäran att se ut som en AJAX-begäran och därmed besegra CSRF-skydd som litar på att AJAX-begäranden har samma ursprung.

Michael Koziarski från Rails-teamet uppmärksammade oss på detta, och vi kunde ta fram ett proof-of-concept som visade samma sårbarhet i Djangos CSRF-hantering.

För att åtgärda detta kommer Django nu att tillämpa fullständig CSRF-validering på alla förfrågningar, oavsett uppenbart AJAX-ursprung. Detta är tekniskt sett bakåtkompatibelt, men säkerhetsriskerna har bedömts vara större än kompatibilitetsproblemen i det här fallet.

Dessutom kommer Django nu att acceptera CSRF-token i den anpassade HTTP-rubriken X-CSRFTOKEN, liksom i själva formuläret, för enkel användning med populära JavaScript-verktyg som gör det möjligt att infoga anpassade rubriker i alla AJAX-förfrågningar.

Se CSRF-dokument för exempel på jQuery-kod som visar denna teknik, och se till att du tittar på dokumentationen för din version av Django, eftersom den exakta koden som krävs är annorlunda för vissa äldre versioner av Django.

FileField raderar inte längre filer

I tidigare Django-versioner, när en modellinstans som innehåller en FileField raderades, tog FileField på sig att också radera filen från backend-lagringen. Detta öppnade dörren för flera potentiellt allvarliga dataförlustscenarier, inklusive rullade transaktioner och fält på olika modeller som refererar till samma fil. I Django 1.2.5 kommer FileField aldrig att radera filer från backend-lagret. Om du behöver rensa bort föräldralösa filer måste du hantera det själv (t.ex. med ett anpassat hanteringskommando som kan köras manuellt eller schemaläggas för att köras regelbundet via t.ex. cron).

Användning av anpassad SQL för att ladda initiala data i tester

Django tillhandahåller en anpassad SQL-krok som ett sätt att injicera egenhändigt utformad SQL i databassynkroniseringsprocessen. En av de möjliga användningarna för denna anpassade SQL är att infoga data i din databas. Om din anpassade SQL innehåller INSERT-satser kommer dessa infogningar att utföras varje gång din databas synkroniseras. Detta inkluderar synkronisering av alla testdatabaser som skapas när du kör en testsvit.

I samband med testningen av Django 1.3 upptäcktes dock att denna funktion aldrig har fungerat helt som utlovat. När du använder databasbackends som inte stöder transaktioner, eller när du använder ett TransactionTestCase, kommer data som har infogats med anpassad SQL inte att vara synliga under testprocessen.

Tyvärr fanns det inget sätt att åtgärda detta problem utan att införa en bakåtkompatibilitet. I stället för att lämna SQL-införda initialdata i ett osäkert tillstånd, tillämpar Django nu policyn att data som infogats av anpassad SQL inte kommer att vara synliga under testning.

Den här ändringen påverkar endast testprocessen. Du kan fortfarande använda anpassad SQL för att ladda data till din produktionsdatabas som en del av syncdb-processen. Om du vill att data ska finnas under testförhållanden bör du antingen infoga dem med test fixtures eller med metoden setUp() i ditt testfall.

ModelAdmin.lookup_allowed signatur ändrad

Django 1.2.4 introducerade en metod lookup_allowed på ModelAdmin, för att hantera ett säkerhetsproblem (changeset [15033]). Även om denna metod aldrig var dokumenterad, verkar det som om vissa människor har åsidosatt lookup_allowed, speciellt för att klara av regressioner som introducerades av denna ändringssats. Även om metoden fortfarande är odokumenterad och inte markerad som stabil, kan det vara bra att veta att signaturen för denna funktion har ändrats.