Når du som jeg bruger OpenId til et projekt, så kan det være frustrerende at OpenId ikke har en “log ud” funktion. Man skal selv styre brugerens “state” og det kan skabe nogle lidt finurlige oplevelser når man gerne vil logge ind. Hvis du tilføjer en extenstion til dit OpenId request så kan du tvinge igennem at brugeren skal logge ind hver gang vedkommende besøger dit site. Et eksempel på dette herunder:

var openId = new OpenIdRelyingParty();
var response = openId.GetResponse();

if (response == null) {
    try {
        var req = openId.CreateRequest( openIdIdentifier );
        req.AddExtension( new PolicyRequest { MaximumAuthenticationAge = TimeSpan.Zero } );
        return MessagingUtilities.AsActionResult( req.RedirectingResponse );
    } catch (ProtocolException exception) {
        //TODO: logging needed here!!!
    }
}

Med IIS 7.x har man mulighed for at trace fejlede requests. Det er smart hvis man oplever at mange requests simpelthen fejler, smider en exception eller evt. udløber. Request tracing efterlader en form for log fil hver gang et request fejler, og de log filer kan man enten gennemgå manuelt eller igennem det jeg har valgt at bygge til formålet – FailedRequestViewer.

Du kan sætte failed request tracer regler på, enten på din webserver (IIS) eller igennem din applikation. Jeg kan så godt lide at fortælle at man har mulighed for at manipulere med IISn igennem applikationens web.config fil, at jeg i dette eksempel simpelthen vil vise hvordan det gøres.

Du kan logge alt hvad mht. fejlede requests ved at indsætte følgende i din web.config fil:

<system.webServer>
    <tracing>
        <traceFailedRequests>
            <add path="*">
                <traceAreas>
                    <add provider="ASP" verbosity="Verbose" />
                    <add provider="ASPNET" 
                         areas="Infrastructure,
                         Module,
                         Page,
                         AppServices" verbosity="Verbose" />
                    <add provider="ISAPI Extension" verbosity="Verbose" />
                    <add provider="WWW Server" 
                         areas="Authentication,
                         Security,
                         Filter,
                         StaticFile,
                         CGI,
                         Compression,
                         Cache,
                         RequestNotifications,
                         Module,
                         FastCGI" 
                         verbosity="Verbose" />
                </traceAreas>
                <failureDefinitions timeTaken="00:00:00" statusCodes="100-999" />
            </add>
        </traceFailedRequests>
    </tracing>
</system.webServer>

Se det er rigtigt super mega smart. Dette giver os nemlig mulighed for at finde ud af rigtig mange ting omkring de requests der har fejlet. Dog er der en ting som ikke er optimal ved dette, nemlig at man pr. default skal gennemgå de her logfiler en efter en. Det holder ikke. Derfor jeg er gået igang med at bygge en oversigt til de her filer, så man får et mere nuanceret overblik over ens failed request filer og i fremtiden måske bruge oversigten til lettere at finde fejl i ens applikation.

og flere detaljer om hvert request

Du kan downloade koden for projektet her.

En ting som rigtig mange stadigvæk ikke er klar over, er muligheden for at extende Windows web serveren, Internet Information Services. Dette emne er noget som Mads Kristensen bestemt har ydet sit for at få udbredt, men om det har nået ud til jer alle er svært at sige. Mads har gentagne gange fortalt mig, at mange af de udviklere han møder simpelthen ikke er klar over denne lækre men efterhånden gamle feature i IIS 7.x.

HttpHandlers…

Har filendelsen .ashx, bruges udelukkende til at håndtere den response der kommer tilbage fra IISn, udfra en bestemt filtype.

Er smarte hvis du f.eks laver UrlRewriting, indholds-manipulation eller andet hvor du gerne vil have fingrene i responsen før klienten modtager det.

Er nemme at bygge, du skal faktik bare have en klasse der arver fra IHttpHandler interfacet.

Behøver ikke registreres på webserveren.

using System;
using System.Web;
using System.IO;

public class TxtHandler : IHttpHandler
{
    public bool IsReusable
    {
        get { return false; }
    }

    public void ProcessRequest(HttpContext context)
    {
        StreamReader reader = new StreamReader
            (context.Server.MapPath(context.Request.FilePath));

        String cardInfo = reader.ReadToEnd();

        context.Response.Write(cardInfo);
    }
}

Ovenstående er en HttpHandler (.ashx) og det eneste du mangler nu er at registrere den. Det kan du gøre på enten server, website eller applikations niveau.

Hvis du vil gøre det på IISn skal du finde det punkt der hedder “Handler mappings”. Her tilføjer du stien og den ønskede type der skal tage sig af responsen.

Du kan også gøre det på selve applikationen, og det kræver såmænd bare tilføjelse af en handler  i din webconfig fil.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.web>
        <compilation debug="true" />
    </system.web>
    <system.webServer>
        <handlers>
            <add 
                name="txtHandler" 
                path="*.txt" 
                verb="*" 
                type="TxtHandler" 
                resourceType="Unspecified" 
                preCondition="integratedMode" 
            />
        </handlers>
    </system.webServer>
</configuration>

Når nogen kalder en .txt fil på dit website vil den ovenstående HttpHandler træde i kræft og du vil have fuld adgang over det pågældende request.

Bemærk at pipeline mode på IISn skal være sat til Intergrated.

Som sagt er Mads Kristensen en haj til at lave de her HttpHandlers, så tjek hele hans bibliotek ud :)

God fornøjelse.