I have noticed that in Intershop7 a configuration value is added in pipelet xml which allows to flag certain parameters as "session" parameters:
By the description, I would assume by enabling this flag pipelet execute method would provide a mean of storing this value in session dictionary. However, I cannot find a description anywhere on the support site of how we should handle the session dictionary within pipelet for "session parameters". Is there a way to do that or it's still recommended to use "ExchangeSessionObject" pipelet for storing objects into session dictionary?
Related
All,
We have several ASP.NET websites that are using the RedisSessionStateProvider for session storage. We are just starting to spin up an instance of ServiceStack, and I would like to pass the sessionId from ASP.NET to ServiceStack, then use the stored values from Redis in ServiceStack sessions.
So far I have been able to pass the sessionID in the header, retrieve it in my plugin, and get the value matching that sessionId from Redis back as a string.
My problem is is a typed object going into Redis from ASP.NET, but I can't get it as the type object coming out in ServiceStack.
Any and all suggestions are appreciated.
Thanks,
B
ServiceStack Sessions are completely decoupled/independent from ASP.NET Sessions and its Session Provider model. As they're 2 completely different technologies they're incompatible with each other, you'll need a separate "migration step" to extract out data from ASP.NET Session State, populate your Typed Custom UserSession and save it in ServiceStack.
ServiceStack Sessions are simply your Typed UserSession persisted in the registered Caching Provider at a key identified from the Cookie SessionId.
Navigating all User Sessions in Cache
The Inspecting Persisted User Sessions illustrates how User Sessions are serialized POCO's stored in the Registered ICacheClient at the following key:
urn:iauthsession:{SessionId}
Where {SessionId} is either the users ss-id or ss-pid cookie depending on whether the user was authenticated with RememberMe=true which instructs ServiceStack to save the session against the ss-pid permanent cookie - this preference is stored in the ss-opt=perm cookie.
Since they're just plain POCO's stored at a predictable key format, we can easily iterate through all user sessions by using the ICacheClient API's directly, e.g:
var sessionPattern = IdUtils.CreateUrn<IAuthSession>(""); //= urn:iauthsession:
var sessionKeys = Cache.GetKeysStartingWith(sessionPattern).ToList();
var allSessions = Cache.GetAll<IAuthSession>(sessionKeys);
I have a MVC4 web app that calls to a WebApi. The WebApi returns a JSON list of objects that are then converted to a appropiate Model and passed to the View.
Currently I am 'caching' this list of objects before its passed to the View in a Session variable that can then be paged through pagination.
I know this is bad. My idea is to store the JSON list in a database.
What I need to do is determine the best way to associate the a JSON item list in the database with the user that requested it. I was thinking of creating a Session variable each time a user first accesses the Controller of the app and then store the ID (based on a GUID) that can then be queried against the database.
Again the above idea requires the use of a Session which is bad. What could I use instead?
Please note I have no Login in system and therefore no 'Users' table so ID's will have to be assigned on the fly.
The data you keep in session will be available to any request from the current session until session expires.
Session is not always bad. There are some valid use cases where you can store some data in session provided you are not using the In-Memory session. Using In-Memory session is bad. You should use a small db table to store the data you wish to keep in session (Ex : Shopping cart data etc..) or if you really want session(why?), you should use StateServer or SqlServer session modes
If you do not wish to keep your app's local db to store this information, You may also consider keeping that in a caching layer instead of session. You may use the MemoryCache class available in dot net.
Quick sample of setting data to the cache.
ObjectCache cache = MemoryCache.Default;
CacheItemPolicy policy = new CacheItemPolicy();
policy.AbsoluteExpiration = DateTime.Now.AddDays(1);
var products = new List<string> { "iPhone","MacBookPro","Beer"};
var userId=25;
var cacheKey="productsOf"+userId;
cache.Set(cacheKey, products, policy);
And to read from the cache,
var userId=25;
var cacheKey="productsOf"+userId;
var test= cache.Get(cacheKey);
Get method returns an object and you need to explicitly cast it to your custom class/data structuer. You can keep any object in the cache. Based on your specific requirement update the expiration date of the cache. MemoryCache class is available in the System.Runtime.Caching namespace.
Similar to in-memory session, cache will be automatically cleared periodically. So your best bet is to use a small local db table i guess.
I want to run some database processing when a user's session expires, but I need to know what user it was whose session expired.
I was considering simply setting the Session["CurrentUserId"] upon login which could then be accessed when the session expires, but thought there might be a way of getting the HttpContext.User.Identity directly from the Session?
Well, looking at the class definition on MSDN, it doesn't looks like you can access it right from a Session's property / member.
However, They are both properties of the same object, which in your case is going to be the current HttpContext. So when the session ends for one context (understand : one http request), the current user of the context is the same as the one you are looking for.
Otherwise, you could always use a hashtable stored in cache where the key would be the Session.SessionId and the value would be the User identity.
Related to that question.
I've understood that I have to create some services for handle my entity and so on. That's because I have to "move" my logic away from controllers and place into "managers" (i.e. services)
Now I have a service that have some logic into it. In that service I, depending on user, return a list of "associated object" - say that those object are sport's team.
Let's say that first element of my list (generated from a repository somehow) is the "default" team and say that I have a page were I can change it FOR all session long.
After log out or sessions stale, I want to return at "default" situation.
So my idea was: "since I've wrote a manager for this entity, I'll write a private attribute in this class where load (from db) this property and store (temporarily, with setter method) my changes."
This doesn't affect my db and I can keep my information for all session long.
But a thought came into my mind: how about session object? (is a service, if I didn't understood wrong)
Is my solution a good solution, or is better to store my information into session object?
From my point of view it's the same except that I can read session's variables directly from twig by using app.session. Am I wrong?
Moreover, if I'm not wrong, how can I access my object properties from twig without each time pass them from controller? (is much like having a global variable that I want to display everywhere into my application pages).
Edit:
More information can be found in this chat transcript.
If you want to store a variable for the duration of a session (for example, login until logout or as long as the user doesn't close his browser window) you have to store it in the session object. If you want to store a variable for the duration of a request, you can store it in the manager service.
However, you can use the manager service to load the session variable and make it available to the controller.
Just like it is a good idea to decouple the controller from the database/Doctrine it is also a good idea to decouple the controller from the session.
Update: As mentioned in the comments when looking at REST it is not a good idea to do the session stuff in the service. However, you should still store the variables in the session and use the controller to set the value in the service.
Here is my issue. I am working on an E-commerce solution that is deployed to multiple European countries. We persist all exceptions within the application to SQL Server and I have found that there are records in the DB that have a DateTime in the future!
We define the culture in the web.config, for example pt-PT, and the format expected is DD-MM-YYYY.
After debugging I found the issue with these 'future' records in the DB is because of Callback methods we use. For example, in our Caching architecture we use Callbacks, as such -
CacheItemRemovedCallback ReloadCallBack = new CacheItemRemovedCallback(OnRefreshRequest);
When I check the current threads CultureInfo, on these Callbacks it is en-US instead of pt-PT and also the HttpContext is null. If an exception occurs on the Callback our exception manager reports it as MM-DD-YYYY and thus it is persisted to SQL Server incorrectly.
Unfortunately, in the exception manager code, we use DateTime.Now, which is fine if it is not a callback. I can't change this code to be culture specific due to it being shared across other verticals.
So, why don't callbacks into ASP.Net maintain context? Is there any way to maintain it on this callback thread? What are the best practices here?
Thanks.
DateTime.Now does not depend on culture. Are you saving it as a string? ToString does depend on culture.
In fact, as a general rule, try to store things in the database in a manner not dependent on culture. This is especially important in a web application, where the culture for each request may be different from the next. In order to be able to "compare apples to apples", you need to ignore culture.
You should separate the DateTime (UTC recommended) from the rest of the error description in your logging management AND also store the culture associated with the log entry. Then you can reassemble the info with these 3 pieces independently.
The cache callback comes on a threadpool thread which in your case always has en-US and there's no HttpContext. You should be able to retrieve the culture by associating the removed cache item with your callback logic.