MVC4 webAPI Session hogyan

WEBAPI esetén MS elspórolta a Session létrehozását és kezelését alapesetben. Van rá mód, hogy legyen Sessionünk, csak egy marker interface kell hozzá:

Ha az ASP.NET MVC Controllert ControllerBase alaposztály szerint használjuk a már megszokott módon lesz Session-ünk a HttpContext-ben, amit a következőképpen lehet elérni:

HttpContext.Current.Session

Azonban ha MVC API-t használunk ami az ApiController osztályból származik, alapesetben nincs session-ünk.

Ahhoz, hogy legyen a következő lépéseket kell megtenni:

1. Saját SessionControllerHandler osztály létrehozása a HttpControllerHandler és az IRequiresSessionState Marker Interface leszármazásával:


public class SessionControllerHandler : HttpControllerHandler, IRequiresSessionState
{
        public SessionControllerHandler(RouteData routeData)
            : base(routeData)
        { }
}

A Marker Interface (IRequiresSessionState) fogja jelezni a Framework-nek, hogy létre kell hoznia a Session-t az eléréséhez.

2. SessionRouteHandler osztály létrehozása, amely az IRouteHandler interfészt valósítja meg

public class SessionRouteHandler : IRouteHandler

{
        IHttpHandler IRouteHandler.GetHttpHandler(RequestContext requestContext)
        {
            return new SessionControllerHandler(requestContext.RouteData);
        }
}

3. Az előbbiek tényleges használata a route tábla létrehozásánál:


RouteTable.Routes.MapHttpRoute(
             name: "DefaultApi",
             routeTemplate: "api/{controller}/{id}",
             defaults: new { id = RouteParameter.Optional }
         ).RouteHandler = new SessionRouteHandler();

A megoldásról többet a következő oldalon olvashatsz:

http://www.strathweb.com/2012/11/adding-session-support-to-asp-net-web-api/

Session kezelés ideje lejárt...

Jól bevált megoldás volt, hogy webes felületen tárolt adatokat a végleges mentésig session-be mented, majd például a varázsló végén DB-be. Vagy bármilyen hasonló session-be tárolt adat esete ráhúzható (kosárkezelés pl.). A fejlődő világban egyre több ember kezeli készséggel a böngészőket és nyit újabb és újabb ablakot bármikor, másolgat ide-oda, a nélkül, hogy bármi fogalma is lenne arról, hogy mi az a "munkamenet". Ez egy rosszul megtervezett rendszerben hamar olyan adatbázis műveleteket vagy folyamat lefolyást eredményez, amire a munkamenetben gondolkozó programozó nem gondolt.
Ezért ma már a tervezés alapmotívuma kell, hogy legyen, hogy session információ tárolásnál át kell gondolni, hogy milyen adatok sérülhetnek a több oldalas böngészőkezeléssel és ezt kell e védeni, pl. egy egyedi pageuid vagy folyamatuid azonosító generálással egy hidden fieldbe, hogy tudd, hogy minden GET-nél újragenerálja. Ezzel ellenőrizhető, hogy új fülön nyitotta meg az oldalt és figyelmeztethető, hogy a varázsló másik ablakban nem használható...

SQL Session DB probléma

Ha ezt az EXCEPTION-t kapod a web appliációtól:
The EXECUTE permission was denied on the object 'TempGetStateItemExclusive3', database 'CafeteriaSessionDB', schema 'dbo'.
Vagy szerinte nincs ASPSTATE DB rendesen feltéve és 2.0-nak megfelelőnek kell lennie, akkor a következő beállítás segít (főleg, ha csökkentett jogokkal bír a user a DB felett):
Magán a létrehozott SessionDB-n properties, majd permissions, ott kiválasztod a usert, majd alatta a listából a Control jog megadása hiányzik.

UserId lenyomása SQL-be

Érdekes észrevétel arra, hogyan lehet MS SQL-ben session contextbe adatot nyomni, ami lehet akár a user SID-je, és innentől kezdve DP, hogy ezt a session nyitásakor beállítod, majd későbbiekben minden update/insert utasítás innen veszi ki, nem kell folyton letolni paraméterbe:
http://msdn.microsoft.com/en-us/library/ms187768.aspx