In the Symfony configuration there is an entry framework.session.storage_id. This setting also appears in the default config on the Symfony configuration documentation but it is not explained. My assumption is that it defines where session data is stored on the server side.
Values I have seen for this entry include session.storage.mock_file, session.storage.native and session.storage.filesystem. I am unsure of what these values exactly mean (e.g. what is the difference between a mock file and a filesystem?) and also think that this is not the complete list of possible values.
So what exactly does this configuration key control and what values are valid?
Valid values for framework.session.storage_id are following:
session.storage.mock_file - for testing. It doesn't start session at all.
session.storage.filesystem - for testing. It is an alias for session.storage.mock_file.
session.storage.native - default implementation using defined session handler
session.storage.php_bridge - for legacy apps
From developer perspective, there is a session service that abstracts working with session. session service depends on some session storage service. Session storage implements session management from PHP perspective (calling session_start() function for example). Storage also depends on some session handler. Handler is implementation of \SessionStorage and it tells how and where will be session physically stored.
This three layer design allows creating storage for testing which does not call session_start() at all and does not use handler (session.storage.mock_file). Or creating of handler that can store and load session from anywhere (session.storage.native). session.storage.php_bridge solves situation when session_start() is called by external PHP code (not by Symfony session storage).
I hope it is clear to understand.
Session management in Symfony is based on two main rules.
Symfony must start the session.
The Symfony sessions are designed to replace the use of PHP native functions session_*() and $_SESSION global.
However, some exceptions exist. Sometimes it may be necessary to integrate Symfony in a legacy application, which starts the session with session_start().
With session.storage.php_bridge directive, you can manage the session using a special gateway that is designed to allow to Symfony working with a session that was started outside the framework.
In goal to make the code using sessions testable, session.storage.mock_file directive allows to simulate the flow of a PHP session without starting it really.
Related
I've read about the automatic configuration reload which - according to the docs - also includes security settings. What I could not figure out yet (and did not see any indications for ) is if Artemis also updates Roles etc. when the LDAP auth is active.
Question is: In an ActiveMQ Artemis deployment where OpenLDAP is used for authentication and authorization do I need to take care about updating the roles etc. myself or is this done automatically?
The documentation you cited is related to reloading broker.xml when a change is detected. It isn't really applicable to the LDAP authorization data since that data is in LDAP and not in broker.xml. However, the documentation for the LegacyLDAPSecuritySettingsPlugin is relevant as it discusses the enableListener option:
enableListener. Whether or not to enable a listener that will automatically receive updates made in the LDAP server and update the broker's authorization configuration in real-time. The default value is true.
Since enableListener defaults to true then changes made to your LDAP authorization data should automatically be reflected in the broker.
The listener is an implementation of both javax.naming.event.NamespaceChangeListener and javax.naming.event.ObjectChangeListener and is registered using the javax.naming.event.EventDirContext#addNamingListener(java.lang.String, java.lang.String, javax.naming.directory.SearchControls, javax.naming.event.NamingListener) method.
That said, you may run into ARTEMIS-2671 which will be resolved in the next release (i.e. 2.12.0). It's also possible that your particular LDAP server doesn't actually support this listener functionality. If that's the case then restarting the broker is your only option to reload the LDAP data. Modifying broker.xml won't reload it.
Is it a bad idea to implement my own session state provider that conditionally switches based on key between the redis session provider and the inproc session provider?
I am working in a very large legacy asp.net application that currently uses the inproc session provider. We are migrating to Redis as a session state provider so that it persists deploys, however the application is chock full of session abuses (e.g. way too large objects, non-serializable object, I saw a thread in there for some reason?).
We plan to slowly correct these abuses but until they are all corrected we cannot really move to redis. I am hoping we can slowly start migrate serializable-safe keys into redis while the abuses remain in memory until we address them.
Does anyone have any advice on this? Or perhaps alternative suggestions for migrating to out of process from in process?
Thanks!
In ASP.NET Web Form and MVC, using Redis for Session State is just a couple of line of modification in Web.config. Then add SerializableAttribute to classes. There is no side effects of applying it to a class.
Based on my experience when migrating to Azure few years ago, Session State is not worth migrating slowly.
Caching is different story. It requires code changes, so we end up implementing two classes - MemoryCacheManager and RedisCacheManager, and register at run-time in IoC container. Then inject ICacheManager to dependent classes.
Source for the session state: https://github.com/Microsoft/referencesource/blob/master/System.Web/State/
Docs: https://learn.microsoft.com/en-us/dotnet/api/system.web.sessionstate?view=netframework-4.7.2
I'd start by checking out the reference source so you can search the codebase. One interface jumps out as potentially interesting.. IPartialSessionState (When implemented in a type, returns a list of zero or more session keys that indicate to a session-state provider which session-state items have to be retrieved.) Source is here
https://learn.microsoft.com/en-us/dotnet/api/system.web.sessionstate.ipartialsessionstate?view=netframework-4.7.2
I stumbled on https://www.wiktorzychla.com/2007/06/wrapped-inprocsessionstatestore.html
via ASPNET : Switch between Session State Providers ?.
This technique could theoretically be used with the Redis provider as well. You'd have to either maintain a list of keys suitable for storing in Redis or do some kind of try to serialize/catch/cache result of which types can be serialized and adaptively fall back to the InProc behavior. You should be able to use HttpContext.Current.Items to flow information between events in the request processing pipeline.
The SessionStateModule (the module responsible for retrieving session, locking, saving, unlocking, etc.) seems to treat InProc as special in a few places. Search its code for InProc. Essentially you're trying to plug in a magical provider that is Custom and yet still has all of the InProc semantics applied by the one and only SessionStateModule. You won't be able to/probably won't want to modify that module, but you may be able to hook up another one adjacent to it that hooks into related events in the request pipeline and does whatever needs to be done that is either In-Proc or Custom-specific. You'll probably run into internal/private methods for which you'd need to use reflection. Not sure how the licensing works on the reference source (MS-PL I think), but another option would be to copy & paste the code from SessionStateModule into your own, make adjustments as needed, unregister the original and register your replacement.
I think you're going to be stuck dealing with a lot of reflection code to get this to work.
I have a ASP.Net API implementation, where to store and access the data / variables across consecutive calls, I am using a session state object as shown below and it can be successfully accessed in the multiple calls to separate calls by a browser:
// Access the current session object
var blSession = HttpContext.Current.Session;
// create the BL object using the user id
BL accessBL = new BL(userID);
// Store the Bl object in the session object dictionary
blSession["UserBL"] = accessBL;
I have to enable the following setting in the Global.asax, for the Session object to be accessible:
protected void Application_PostAuthorizeRequest()
{
// Enable session state in the web api post authorization
HttpContext.Current.SetSessionStateBehavior(SessionStateBehavior.Required);
}
Issue comes in when the WebAPI shown above has to be accessed via another ASP.Net MVC client, which is separately hosted on a different machine, at that time same consecutive calls do not maintain the state as shown above and thus it leads to an exception, since the consecutive calls rely on session data to proceed.
I have seen a similar issue when I seen the similar issue when I use the Fiddler Debugger, as it gets hosted as a web proxy, so consecutive calls through that too fails, since it does not maintain the state. In my understanding, issue is due to setting the Cookie across domain, which doesn't seem to work across domains due to security reason
I know a workaround is to use an application wide variable like Cache, but please suggest if you have a way to get the SessionState work. Let me know if you need more details.
If you have not setup an alternative way to do SessionState, then the default behavior is to do it InMemory on the server. This is why you are seeing issues when the request is handled by a different ASP.NET server.
Web API calls are meant to be stateless. That is, they should not perform like a classic ASP.NET application that relies on the framework to store user specific information in Session variables across HTTP requests. For each call, pass in a user-specific identifier or token that you can then use to lookup information stored in your backend. You can store this information in your database or a distributed cache like MemCache for faster retrieval.
Hi I am working in a symfony real time app using Ratchet Library, In my app I need to send some data to a specific user.And the only way to do this is to attach a symfony session object to each incoming Connection object.
I have read the doc here but I can't understand it and how to make it work in symfony?
As the documentation states need to setup a non-native session handler to store your sessions i.e. in a database via PDO.
Then you need to configure Ratchet to use your session handler. If you're using ClankBundle you can read this documentation chapter.
I have an ASP.NET application which requires output caching. I need to invalidate the cached items when the data returned from a web service changes, so a simple duration is not good enough.
I have been doing a bit of reading about cache dependencies and think I have the right idea. It looks like I will need to create a cache dependency to my web service.
To associate the page output with this dependency I think I should use the following method:
Response.AddCacheItemDependency(cacheKey);
The thing I am struggling with is what I should add to the cache?
The dependency my page has is to a single value returned by the web service. My current thinking is that I should create a Custom Cache Dependency via subclassing CacheDependency, and store the current value in the cache. I can then use Response.AddCacheItemDependency to form the dependency.
I can then periodically check the value and for a NotifyDependencyChange in order to invalidate my cached HTTP response.
The problem is, I need to ensure that the cache is flushed immediately, so a periodic check is not good enough. How can I ensure that my dependant object in the cache which represents the value returned by the web service is re-evaluated before the HTTP response is fetched from the cache?
Regards, Colin E.
I believe you are on the right track with your cache dependency. However, if you don't "periodically check" the return value of the web service, how can you know when it returns a new value? You may need to set up a web service in the other direction, so that when the value changes in the other system, it can call your system and invalidate the old cache and stick in the new value.
You can manually invalidate a cached page using:
System.Web.HttpResponse.RemoveOutputCacheItem(path)