Hey! First post for me but long time reader of Stackoverflow.
Anyway, got a tricky problem wich is getting on my nerves. It's questions about how configurable should a DIC (Dependency Injection Container) be. I'm working on a session handler for our framework we are setting up. The session handler is dependent on a storage service, some simple configuration parameters and is the one that generates a session id with a salt.
Session handler is loaded by our container wich takes all the settings, either as a configurator object or an array of parameters. The container checks the setting for what storage service is called for and loads the service and injects it to the session handler. The storage service does not take any constructor settings at the moment.
Session handler in it's turn generates the session id from the settings it got injected. And from there injects the session id and other settings relevant to the that storage service.
My questions are:
Is it proper to let the Session Handler inject settings to storage service? It's like a 2 step rocket.
Should I inject the session id and other parameters from start when I load the storage service in the container? Wich in the end leaves me with the problem of generating the session ID and have to rely on the storage service to do it.
What problems would arise if I did either way from above proposals?
Am I breaking anything "holy" :)
I am a bit confused by this part:
Session handler in it's turn generates
the session id from the settings it
got injected. And from there injects
the session id and other settings
relevant to the that storage service.
You already said that the session handler is dependent on the storage service. It would be a bad idea for the storage service to also have some dependency on session handler, because then your initialization process is way more complex and error prone than it needs to be.
So here's the question: what settings does the storage service need from the session handler? Can you remove any or all of these dependencies from the storage service? If so, you should do so.
As a practical example: let's say the storage service supports storage of data as named blobs (which may be implemented as files, or as rows in a database table, or whatever else). You use a name dependent on the session id to store the session data. What you need to do is not tell the storage service what the session id is, but have the session handler remember it instead and provide that information to the storage service only whenever it uses storage functionality.
In other words, try to keep your data grouped logically. Is there a specific problem that prevents you from doing so?
Related
I'm developing an application that will need to provide certain state to users in real time. Every user will use an AJAX script to 'watch' that state - every user will see all of the shared state. I'm concerned about security, since some of the shared state are secretive data.
I've tried to implement this with environment variables in .env, but I need arrays and I think .env is not compatible with arrays.
I've also tried using globals without success.
My final attempt was to use a config file and the config helper from laravel, but changes to the state weren't saved! I have thought about using a database table, but I don't know how to make it safe.
How should I approach this problem?
Each time when I update my application on AppFog then all logged in users are logging out automatically.
Because of session lost!
How can I solve this problem?
The application has built in PHP on top of Yii Framework 1.1.14
The problem is, that Yii uses CApplication::getId() to generate cookie ID. This method uses basePath to generate that ID.
return $this->_id=sprintf('%x',crc32($this->getBasePath().$this->name));
As you deploy new version, the base path of your application changes, so cookie ID is regenerated and sessions are lost.
The solution would be to specify your own application ID in protected/config/main.php
"id" => md5(php_uname().'somHardGuessableRandomString'),
somHardGuessableRandomString part should be randomly generated.
It may be either due to session or due to authorisation file being overwritten during an update..
refer: http://www.yiiframework.com/doc/api/1.1/CHttpSession#savePath-detail
and http://in2.php.net/manual/en/session.configuration.php#ini.session.save-path
The authorisation temp file is stored in /protected/data/auth.php by default.
You can avoid this by either specifying a different path to those files,
the session file defaults to php session save path, or moving the session management to the DB. Using CDbHttpSession instead of CHttpSession and CDbAuthManager instead of CPhpAuthManager respectively, this article explains session management in yii in more detail.
It is more likely an authorisation issue as the application, directory get overwritten during an update rather than system tmp directories. If you use version control to update your app you can configure it to ignore this file (.gitignore or equivalent).
The AppFof filesystem is not persistent. When you update you are rebuilding the application to essentially a new server so anything stored in the filesystem is lost, including the session files.
Probably the only solution is to save the session details to a database.
I have a PHP system that i'd like to port to be on more than one server if the need arises. Currently I store the user's current session information just in the default manner PHP does (assuming in memory). Can I get an example of what I need to put in a table in my MySQL database as well as some example of implementation?
The default session storage system is actually on the file system. Some system caching may be used to pull it from memory.
Now in order to go into a multi-server setup, your servers need to basically share nothing with each other. To that goal, sessions need to be stored outside of the server they are created and accessed on.
Storing sessions in the database is one option, but it increases the load on your database and you have to be careful with locking in some cases. Default session handling has locking which allows only one thread to access a given session at a time, a database handler may not do that. If you are only reading session data, this is likely not going to be a problem, but if you are changing it, it could be.
The memcached extensions allow for session data replication to memcached nodes. I prefer this route as it allows you to keep sessions in memory and avoids adding extra db load (which is often more difficult to scale)
I am writing a brand new website and I'd like to make sure that it scales out easily if I ever get to the point where I must host the site on multiple machines with a load balancer.
The user of the website can be authenticated. In other words, I need to maintain some state information. My first reflex was to use Session variables but then I am going to be limited to a single machine. I know that there are ways to store the session variables outside (in a DB, redis, memcached) but is that the only options?
What are the alternative to session variable? How Facebook and other big web sites are doing this?
P.S. I am not looking for another session handler (DB, redis, etc.). I'd like to know if there a way to completely get rid of session variables.
Ever heard of session_set_save_handler? It allows you to use mechanisms other than the default PHP session handler (the one that writes sess_xxxxxxxxxxxx files in tmp directory).
You can write your own session handler that uses a database. This could be a time consuming task; so you can stick with the default PHP session handlers for the time being and transparently switch to database when you are ready. You probably won't have to rewrite any code except implementing and plugging in your version of the six session handling functions.
You can look into caching, i.e using Zend cache or APC cache, for example.
I'm on board with the whole cookieless domains / CDN thing, and I understand how just sending cookies for requests to www.yourdomain.com, while setting up a separate domain like cdn.yourdomain.com to keep unnecessary cookies from being sent can help performance.
What I'm curious about is if using PHP's native sessions have a negative effect on performance, and if so, how? I know the session key is kept track of in a cookie, which is small, and so that seems fine.
I'm prompted to ask this question because in the past I've written my web apps and stored a lof of the user's active data, preferences, and authentication information in the $_SESSION variable. However, I notice that some popular web applications out there, like Wordpress, don't use $_SESSION at all. But sessions are easy to use and seem fairly secure, especially if you combine it with tracking user-agent / ip changes to prevent session hijacking. So why don't Wordpress and other web apps use php's sessions? Should I also stop using sessions?
Also, let me also clarify that I do realize the server must load the session data to process a page request, but that's not what I'm asking about here. My question is about if / how it impacts the network performance, especially in regard to the headers being sent / received. For example does using sessions prevent pages or images on the site from being served from the browser's cache? Is the PHPSESID cookie the only additional header that is being sent? These sorts of things.
The standard store for $_SESSION is the file-system with one file per session. This comes with a price:
When two requests access the same session, one request will win over the other and the other request needs to wait until the first request has finished. A race condition controlled by file-locking.
Using cookies to store the session data (Wordpress, Codeigniter), the race-condition is the same but the locking is not that immanent, but a browser might do locking within the cookie management.
Using cookies has the downside that you can not store that much data and that the data get's passed with each request and response. This is likely to trigger security issues as well. Steal the cookie and you've got the data. If it's encrypted, an attacker can try to decrypt it to gain the data stored therein.
The historical reason for Wordpress was that the platform never used the PHP Sessions. The root project started around 2000, it got a lot of traction in 2002 and 2004. As session handling was only available with PHP 4 and PHP 3 was much more popular that time.
Later on, when $_SESSION was available, the main design of the application was already done, and it worked. Next to that, in 2004/2005 wordpress decided to start a commercial multi-blog hosting service. This created a need in scaling the application(s) across servers and cookies+database looked more easy for the session/user handling than using the $_SESSION implementation. Infact, this is pretty easy and just works, so there never was need to change it.
For Codeigniter I can not say that much. I know that it stores all session information inside a cookie by default. So session is just another name for cookie. Optionally it can be encrypted but this needs configuration. IIRC it was said that this has been done because "most users do not need sessions". For those who need, there is a database backend (requires additional configuration) so users can change from cookie to database store transparently within their application. There is a new implementation available as well that allows you to change to any store you like, e.g. to native PHP sessions as well. This is done with so called drivers.
However this does not mean that you can't achieve the same based on $_SESSION nowadays. You can replace the store with whatever you like (even cookies :) ) and the PHP implementation of it should be encapsulated anyway in a good program design.
That done you can implement a store you can better control locking on (e.g. a database) and that works across servers in a load balanced infrastructure that does not support sticky sessions.
Wordpress is a good example for an own implementation of sessions handling totally agnostic to whatever PHP offers. That means the wheel has been re-invented. With a view from today, I would not call their design explicitly innovative, so it full-fills a very specific need in a very specific environment that you can only understand if you know about the projects roots.
Codeigniter is maybe a little step ahead (in an interface sense) as it offers some sort of (unstable) interface to sessions and it's possible to replace it with any implementation you like. That's much better for new developers but it's also sort of re-inventing the wheel because PHP does this already out of the box.
The best thing you can do in an application design is to make the implementation independent from system needs, so to make the storage mechanism of your session data independent from the rest of the program flow. PHP offers this with a pretty direct interface, the $_SESSION array and the session configuration.
As $_SESSION is a superglobal array you might want to prevent your application to access it directly as this would introduce global state. So in a good design you would have an interface to it, to be able to fully abstract away from the superglobal.
Done that, plus abstraction of the store plus configuration (e.g. all in one session dependency container), you should be able to scale and maintain your application well over as many servers as you like for whatever reason. Your implementation then can just use cookies if you think that's it for you. However you will be able to switch to database based session in case you need it - without the need to rewrite large parts of your application.
I'm not 100% confident this is the case but one reason to avoid the built-in $_SESSION mechanism in PHP is if you want to deploy your web application in a high-availability web farm scenario.
Because the default session behavior in PHP is to store session objects in process, in memory, it makes it hard (if not impossible) to have multiple servers processing requests from the same user. You would only have this if you wanted to deploy your web application in a web farm environment where you have a number of PHP web servers processing requests for your app to balance the load.
So, while in-process session state is generally much faster than a database-based solution, the latter is favorable when you need to process a huge number of requests and to service the capacity a web-farm environment is used.
As I said in the beginning, I'm not 100% sure if PHP supports configuring the session state provider to be a database, or session state server, instead of the in-process default.