DotNetNuke er en åpen kildekode web content management system som er bygget på ASP.net infrastruktur og utelukkende har sitt liv ledning som går jevnt på Microsoft plattform. Videre er det en åpen kildekode web content management system som startet i år 2002 av et team av utviklere som ble ledet av den opprinnelige skaperen Shaun Walker som skjer å ha sikret seg sin sertifisering som en sertifisert Microsoft Most Valuable Professional i år 2004.
Sikre innlogging på DotNetNuke området er svært viktig, men ofte oversett av feil årsaker. Det bør ikke være fordi SSL legger en forestilling overhead til nettstedet ditt. Det bør ikke være fordi SSL-sertifikater er dyre heller. Men mest av alt, bør det ikke være fordi det er vanskelig!
La oss først se på resultatene overhead for å bruke SSL. Det er et par store spørsmål om dette temaet på Stackoverflow, her og her. Eldre forskning synes å peke på en rimelig mengde overhead, men en nyere interessant anekdote trekker i motsatt retning. Vanligvis bruker strøm, moderne maskinvare, bør det ikke være en stor innvirkning på ytelsen, men for store og travle områder, er det alltid en god idé å inkludere SSL i lasttesting.
Prising av SSL-sertifikater bør heller ikke være et problem. Hvis du er virkelig på et lavt budsjett er det en rekke gratis SSL leverandører tilgjengelig. Dette er selvfølgelig avhengig av betydningen av området du arbeider på, som du kanskje ikke ønsker å bruke en gratis sertifikat.
Nå, for temaet for dette innlegget: hvordan sette opp en sikker pålogging for DotNetNuke nettstedet. Denne gjennomgangen er i stor grad basert på et blogginnlegg av Troy Hunt, OWASP Top 10 for .NET utviklere del 9: Utilstrekkelig Transport Layer Protection. I dette innlegget forklarer Troy i stor detalj at det er ikke nok å bare ha en sikker (SSL) innlogging, men alle etterfølgende forespørsler må også være sikker, ellers godkjenning cookie kan fortsatt bli kapret i visse situasjoner (for eksempel usikre WiFi-tilkoblinger ).
Heldigvis gir ASP.NET en veldig enkel løsning på dette: endre skjemaer godkjenningsinnstillingen i web.config til å kreve SSL for autentisering cookies. Når du gjør dette, blir autentiseringen cookie ikke lenger bli sendt ut via en usikker (HTTP) tilkobling. Dette betyr at du bare kan logge på et nettsted via en SSL-tilkobling, og når du endre tilbake til en ikke-SSL-tilkobling, vil du bli logget av automatisk.
For å sette dette opp for DotNetNuke nettstedet, må du endre dette:
i dette:
Dette betyr at fra nå av alle godkjennings cookies vil bare bli sendt hvis transportlaget er sikret. Så hold av på å gjøre denne endringen med en gang, som å gjøre dette vil hindre at du logger deg på !. Først må du forberede DotNetNuke å arbeide med en SSL bare pålogging.
Trinn 1: Aktiver SSL for nettstedet ditt i IIS
Jeg er egentlig ikke tenkt å forklare det her, siden dette er en veldig vanlig prosedyre i IIS. Se her for mer informasjon om hvordan du gjør det.
2. Aktiver SSL for nettstedet ditt i DotNetNuke
DotNetNuke tilbyr en omfattende måte å aktivere og håndheve SSL per nettsted (portal). For denne oppgaven, er det nok at SSL er aktivert for området. For å gjøre det, gå til Administrator> Innstillinger for webområde, til kategorien Avansert, og åpne SSL-innstillinger delen. I denne delen, sjekk alternativet "SSL aktivert?", Og oppdatere innstillingene.
3. Lag en sikker pålogging Page
Som standard er automatisk generere innloggingssiden (eller popup) for DotNetNuke er ikke sikker. For å gi en sikker pålogging alternativet, må du opprette en egen side, som har en konto Pålogging modul på den og som er merket som sikker. Mens du kan opprette denne siden på alle nivåer, og gi den et navn, mest logiske ville være å lage denne siden på rotnivå og gi den navnet "Logg inn". Selv DotNetNuke vil håndtere alt automatisk når du gjør alle nødvendige justeringer, det gir meg trygghet å vite at du overskriver den automatisk URL for påloggingssiden.
I full, må den nye innloggingssiden disse egenskapene satt:
Sidenavn: Logg
Root nivå (ingen overordnede siden)
Tillatelser: view tillatelser for alle brukere (eller for uautoriserte brukere)
Secure: Secure flagg må settes (dette vil sikre siden er bare synlig ved hjelp av HTTPS-protokollen, og DotNetNuke vil automatisk bytte til HTTPS for denne siden)
til slutt, satte en konto Pålogging modul på siden.
4. Bruk den nye påloggingssiden
Uten "forteller" DotNetNuke å bruke denne nye innloggingssiden, vil det fortsette å bruke den automatiske påloggingsalternativ. Påloggingssiden er en såkalt spesiell side som betyr at plasseringen av denne siden er lagret per Nettstedet og kan brukes av andre prosesser i en modul eller forlengelse. For å endre den spesielle innloggingssiden, går du til Admin> Nettstedsinnstillinger, og åpne "Advanced Settings" -kategorien, og velg Page Ledelse delen. I denne seksjonen på "Login Page", velg den nyopprettede innloggingssiden, og oppdatere innstillingene.
5. Aktiver RequireSSL
Åpne opp filen web.config for søknaden din, og endre skjemagodkjenning node å se slik ut:
påminnelse
Det er en stor påminnelse her. Siden Skjemaer innstillingen Authentication Cookie er gjort på applikasjonsnivå, i web.config, forutsetter denne løsningen at du enten har bare ett område konfigurert i DotNetNuke, eller at alle nettsteder kan være sikret med SSL-sertifikatet som du brukte til IIS webområdet . Dette betyr at potensielt du må bruke flere SSL-sertifikater til en IIS nettside.
SSL-sertifikater er vanligvis bare gyldig for ett domene, eller for et domene og alle underdomener (sistnevnte er såkalte wild card SSL sertifikater). Eller du kan være i stand til å få et sertifikat for flere ikke-relaterte domener (såkalt (UCC eller SAN-sertifikater). Den beste løsningen ville skjønt være å kjøre under Windows 2012, så dette støtter Server Name Indikasjon (SNI), som gjør det mulig å søke flere SSL-sertifikater til en nettside (ved hjelp av ulike vert hoder). Det er vesentlig for en annen bloggpost om!