Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Sessions

Demis Bellot edited this page · 29 revisions

  1. Getting Started

    1. Creating your first project
      1. Create Service from scratch
    2. Your first webservice explained
    3. ServiceStack's new API Design
    4. Designing a REST-ful service with ServiceStack
    5. Example Projects Overview
    6. Learning Resources
  2. Reference

    1. Order of Operations
    2. The IoC container
    3. Configuration and AppSettings
    4. Metadata page
    5. Rest, SOAP & default endpoints
    6. SOAP support
    7. Routing
    8. Service return types
    9. Customize HTTP Responses
    10. Plugins
    11. Validation
    12. Error Handling
    13. Security
    14. Debugging
    15. JavaScript Client Library (ss-utils.js)
  3. Clients

    1. Overview
    2. C#/.NET client
    3. Add ServiceStack Reference
      1. C# Add Reference
      2. F# Add Reference
      3. VB.NET Add Reference
      4. Swift Add Reference
      5. Java Add Reference
    4. Silverlight client
    5. JavaScript client
      1. Add TypeScript Reference
    6. Dart Client
    7. MQ Clients
  4. Formats

    1. Overview
    2. JSON/JSV and XML
    3. ServiceStack's new HTML5 Report Format
    4. ServiceStack's new CSV Format
    5. MessagePack Format
    6. ProtoBuf Format
  5. View Engines

    1. Razor & Markdown Razor
    2. Markdown Razor
  6. Hosts

    1. IIS
    2. Self-hosting
    3. Messaging
    4. Mono
  7. Security

    1. Authentication/authorization
    2. Sessions
    3. Restricting Services
  8. Advanced

    1. Configuration options
    2. Access HTTP specific features in services
    3. Logging
    4. Serialization/deserialization
    5. Request/response filters
    6. Filter attributes
    7. Concurrency Model
    8. Built-in caching options
    9. Built-in profiling
    10. Form Hijacking Prevention
    11. Auto-Mapping
    12. HTTP Utils
    13. Virtual File System
    14. Config API
    15. Physical Project Structure
    16. Modularizing Services
    17. ServiceStack Integration
    18. Embedded Native Desktop Apps
    19. Auto Batched Requests
    20. Versioning
  9. Server Events

    1. Overview
    2. JavaScript Client
    3. C# Server Events Client
    4. Redis Server Events
  10. Encrypted Messaging

    1. Overview
    2. Encrypted Client
  11. Plugins

    1. Auto Query
    2. Server Sent Events
    3. Swagger API
    4. Postman
    5. Request logger
    6. Sitemaps
    7. Cancellable Requests
    8. CorsFeature
  12. Tests

    1. Testing
    2. HowTo write unit/integration tests
  13. ServiceStackVS

    1. Install ServiceStackVS
    2. Add ServiceStack Reference
    3. AngularJS App Template
    4. ReactJS App Template
  14. Other Languages

    1. FSharp
      1. Add ServiceStack Reference
    2. VB.NET
      1. Add ServiceStack Reference
    3. Swift
      1. Swift Add Reference
    4. Java
      1. Add ServiceStack Reference
      2. Android Studio & IntelliJ
      3. Eclipse
  15. Deployment

    1. Deploy Multiple Sites to single AWS Instance
      1. Simple Deployments to AWS with WebDeploy
    2. Advanced Deployments with OctopusDeploy
  16. Install 3rd Party Products

    1. Redis on Windows
    2. RabbitMQ on Windows
  17. Use Cases

    1. Single Page Apps
      1. HTML, CSS and JS Minifiers
    2. Azure
      1. Connecting to Azure Redis via SSL
    3. Logging
    4. Bundling and Minification
    5. NHibernate
  18. Performance

    1. Real world performance
  19. How To

    1. Sending stream to ServiceStack
    2. Setting UserAgent in ServiceStack JsonServiceClient
    3. ServiceStack adding to allowed file extensions
    4. Default web service page how to
  20. Future

    1. Roadmap
Clone this wiki locally

The AuthFeature (plugin) already enables the SessionFeature, but if you want to make use of sessions and don't want to enable the built-in Authentication, you will need to register it manually in your AppHost with:

public override void Configure(Container container)
{
    Plugins.Add(new SessionFeature());
}

When the SessionFeature is enabled, a Global RequestFilter is added to ServiceStack to ensure that all requests have a Temporary ss-id and a Permanent ss-pid session cookies set. These Session Cookies contain a unique Random Base64-encoded Id. The ss-opt cookie stores the users preference on whether they want their current session to be temporary (ss-opt=temp) or permanent (ss-opt=perm) - i.e. to RememberMe or not - The Default is Temporary.

Permanent and Temporary Session Ids

The Permanent session cookie ss-pid is always created even if ss-opt is Temporary - this allows you to link and track subsequent requests together which can be helpful for user request analyzing. In contrast the temporary Session Id ss-id uses a temporary cookie that does not persist across a users browser sessions.

If you're interested in the implementation, all the source code for ServiceStack's Sessions are kept in the ISession, SessionFeature, SessionFactory, SessionExtensions and ServiceExtensions classes.

Can be used with any ICacheClient

ServiceStack's implementation of Sessions are clean, in that they work with all of ServiceStack's Caching Providers and are simply pointers to POCOs in your Cache. An example of getting ServiceStack to use an in-memory cache:

container.Register<ICacheClient>(new MemoryCacheClient());

Formatting of Keys used in Cache Providers

For typed or Custom AuthSession the key is:

urn:iauthsession:{sessionId}

When using un-typed Session Bag the key is:

sess:{sessionId}:{key}

The general recommendation is to use typed sessions, which will give you type-safety benefits as well as being able to fetch your entire users session with a single cache call. If you use the dynamic/session bag then it will be a network call for each key accessed - although as caches are designed for fast-access, this isn't too much of a concern.

Using Typed Sessions in ServiceStack

An example of using Typed Sessions is in the Social Bootstrap Api demo where a CustomUserSession is defined as:

[DataContract]
public class CustomUserSession : AuthUserSession 
{
    [DataMember]
    public string CustomId { get; set; }
}

By inheriting AuthUserSession you're able to keep all the users session together in 1 POCO, which allows you to access everything in 1 cache read or write.

When inheriting from AuthUserSession you will need to annotate your properties with [DataMember] as AuthUserSession is a DataContract class.

To tell ServiceStack to use your Custom Typed Session instead, register it in the AuthFeature plugin:

Plugins.Add(new AuthFeature(() => new CustomUserSession(), ...));

Session events

Inheriting from the AuthUserSession also lets you add custom logic for different events in the User Session life-cycle:

virtual void OnCreated(IRequest httpReq) {}
virtual void OnRegistered(IServiceBase registrationService) {}
virtual void OnAuthenticated(IServiceBase authService, IAuthSession session, 
    IAuthTokens tokens, Dictionary<string, string> authInfo) {}
virtual void OnLogout(IServiceBase authService) {}

Auth Events

The same authentication hooks that are available in the Custom UserSession above are also available in IAuthEvents API:

public interface IAuthEvents
{
    void OnRegistered(IRequest req, IAuthSession session, IServiceBase registerService);
    void OnAuthenticated(IRequest req, IAuthSession session, IServiceBase authService, 
        IAuthTokens tokens, Dictionary<string, string> authInfo);
    void OnLogout(IRequest req, IAuthSession session, IServiceBase authService);
    void OnCreated(IRequest req, IAuthSession session);
}

The new AuthEvents API provide a loose-typed way where plugins can tap into the same hooks by registering it with AuthFeature.AuthEvents, e.g:

public class WebSudoFeature : IPlugin, IAuthEvents
{
    public void Register(IAppHost appHost)
    {
        ...
        var authFeature = appHost.GetPlugin<AuthFeature>();
        authFeature.AuthEvents.Add(this);
    }

    // Add implementations of all `IAuthEvents` handlers
    public void OnCreated(IRequest httpReq, IAuthSession session) { ... }
}

An alternative way for accessing IAuthEvents is to register it like a normal dependency, e.g:

container.RegisterAs<LogAuthEvents,IAuthEvents>();

To simplify custom implementations you can inherit from the empty concrete AuthEvents and choose to only implement the callbacks you're interested in, e.g:

public class LogAuthEvents : AuthEvents
{
    public static ILog Log = LogManager.GetLogger(typeof(LogAuthEvents));

    public override void OnLogout(IRequest httpReq, IAuthSession session, IServiceBase authService) 
    {
        Log.DebugFormat("User #{0} {1} has logged out", session.UserAuthId, session.UserName);
    }
}

Accessing Typed Session

You can access your custom UserAuth session inside your service using the SesssionAs<T>() extension method, e.g:

public abstract class MyService : Service 
{
    public object Get(MyRequest request)
    {
        var typedSession = this.SessionAs<CustomUserSession>();
    }
}

Adding a Convenience wrapper

To provide a typed, Convenient API for your service you can add the following to a base class, here's SocialBootstrapApi's AppServiceBase example:

public abstract class AppServiceBase : Service {
    private CustomUserSession userSession;
    protected CustomUserSession UserSession {
        get {
            return base.SessionAs<CustomUserSession>();
        }
    }
}

This will then enable you to access your users Session in your ServiceStack services with base.UserSession.

Sharing ServiceStack's Typed Sessions in MVC and ASP.NET

ASP.NET's Session Provider model still maintains its old legacy .NET 1.0 roots with it's heavy XML-encumbered config model, it's coupled and un-testable API, and its degrading performance limitations by design makes it difficult for any web service framework to share the same User Sessions with the base ASP.NET Web Forms or MVC web host.

ServiceStack gets around these limitations by providing its own de-coupled, testable and dependency-free ICacheClient and ISession APIs - which all work simply together as they're just plain Guid Session Keys stored in Caches pointing to POCOs.

The method SessionFeature.GetSessionKey allows you to get a Session Key for a current request if you are trying to access it in ASP.NET Web Forms or MVC web host. Using a Session Key you can have a full control over Session object:

// CacheClient is instance of ICacheClient

var sessionKey = SessionFeature.GetSessionKey();

// geting an existing User Session or create a new one 
var userSession = SessionFeature.GetOrCreateSession<AuthUserSession>(CacheClient); 
// or SessionFeature.GetOrCreateSession<CustomUserSession>(CacheClient); 

// modifying User Session
userSession.UserAuthId = model.UserName;

// saving User Session
CacheClient.CacheSet(sessionKey , userSession);

Saving in Service

As a typed session is just a disconnected POCO, it needs to explicitly saved to be persisted - which you can do with the base.SaveSession() Extension method.

Typed Sessions in MVC

To make use of it in MVC, you effectively do the same thing, although this time you can simply inherit the existing ServiceStackController which has the above templated code in a generic MVC Controller Template:

public class ControllerBase : ServiceStackController<CustomUserSession> {}

From there it's just a basic property which you can use in your Controller or assign to your views like this:

public partial class HomeController : ControllerBase 
{
    public virtual ActionResult Index() 
    {
        ViewBag.Message = "MVC + ServiceStack PowerPack!";
        ViewBag.UserSession = base.UserSession;
        return View();
    }   
}

Typed Sessions in ASP.NET Web Forms

It's the same thing in ASP.NET Web Forms although this comes in the form of a base ASP.NET Web Page which you get for free when you install ServiceStack via the ServiceStack.Host.AspNet NuGet package.

Using Dynamic / Untyped Sessions in ServiceStack

You can access the dynamic UserSession Bag in ServiceStack services via the base.Session property already built-in ServiceStack's ServiceBase base class, e.g:

base.SessionBag["cart"] = new Cart { ... };
var cart = base.SessionBag.Get<Cart>("cart");

Use HTTP Headers to Send Session Cookies

You can now make a Session-enabled request with HTTP Headers instead of Cookies. The Session HTTP Headers have a X- prefix before the Session Id, i.e: X-ss-id, X-ss-pid and X-ss-opts.

Community Resources

Something went wrong with that request. Please try again.