We have recently migrated from ServiceStack V3 to V4, mainly because we want to use push services with the ServerEvents feature. However, we are struggling with how to get it to work in our use case. We don’t currently use any of the built-in authentication or session management features, but have our own authentication modules and sessions in place, these rely on request filters to secure services and our own (differently named) cookies. ServiceStack’s ServerEvents feature seems to be tied closely to authentication feature. Can anyone advise which way to go? Do we need to change authentication to the built-in modules? Should we use our own ServerEvents feature and wire it to our authentication/session management?
You can use Server Events anonymously but if you want to access the authenticated features you should at least save a typed AuthUserSession with the UserInfo of the Authenticated user which you can save with the Session API’s after registering SessionFeature plugin. You can find info about ServiceStack sessions at:
Although the recommendation would be to take advantage other Auth features in ServiceStack by using a Custom AuthProvider instead.
Demis, thanks for your answer. We are still struggling on how to use SessionFeature without AuthenticationFeature so we can use ServerEvents backed with ServiceStack’s sessions.
So you are basically saying to call SaveSession in a service with our own user details, or even to save/update the session with each call of an authenticated user? As long as we restrict ServerEvents to authenticated users and flag all stored sessions with AuthUserSession.IsAuthenticated=true we should be safe so that nobody can actually hook in without passing our (separate) authentication layer to catch events, right?
The Session just needs to be saved once, which then gets persisted in the registered Cache (i.e. ICacheClient). Only the Server can save the Session so if you don’t use the AuthenticationFeature there’s no longer any code in ServiceStack that will create and save the session, so yes no-one would be able to by-pass your custom Authentication layer since it remains the only way a Session gets created and persisted.
Note to be able to save sessions and you’re not registering the AuthFeature, you’ll need to manually register the Session feature, i.e:
Plugins.Add(new SessionFeature());