-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Sessions
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 or permanent (i.e. to RememberMe or not - Default is Temporary).
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());
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.
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.
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) {}
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>();
}
}
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
.
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);
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.
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();
}
}
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.
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");
- Why ServiceStack?
- Important role of DTOs
- What is a message based web service?
- Advantages of message based web services
- Why remote services should use separate DTOs
-
Getting Started
-
Designing APIs
-
Reference
-
Clients
-
Formats
-
View Engines 4. Razor & Markdown Razor
-
Hosts
-
Security
-
Advanced
- Configuration options
- Access HTTP specific features in services
- Logging
- Serialization/deserialization
- Request/response filters
- Filter attributes
- Concurrency Model
- Built-in profiling
- Form Hijacking Prevention
- Auto-Mapping
- HTTP Utils
- Dump Utils
- Virtual File System
- Config API
- Physical Project Structure
- Modularizing Services
- MVC Integration
- ServiceStack Integration
- Embedded Native Desktop Apps
- Auto Batched Requests
- Versioning
- Multitenancy
-
Caching
-
HTTP Caching 1. CacheResponse Attribute 2. Cache Aware Clients
-
Auto Query
-
AutoQuery Data 1. AutoQuery Memory 2. AutoQuery Service 3. AutoQuery DynamoDB
-
Server Events
-
Service Gateway
-
Encrypted Messaging
-
Plugins
-
Tests
-
ServiceStackVS
-
Other Languages
-
Amazon Web Services
-
Deployment
-
Install 3rd Party Products
-
Use Cases
-
Performance
-
Other Products
-
Future