I dabble in PHP. In the projects I've done I always use the database and a cookie to handle sessions. I've seen "session functions" such as session_start() being used also in other sources. I'm just curious, which is better? Should I be using one or another?
Well, there's three ways that I've used through-out time:
The traditional $_COOKIE-way, meaning that you actually use cookies to store values
The "new" $_SESSION-way, where you use an associative array that probably relies on a cookie
Using $_SESSION in conjunction with the DB, making sessions controllable on a user-basis.
I prefer using option #3, as it both enables me to alter sessions "on-the-fly", as well as track the logged in users easier.
Options #3 would play out in the following way (semi-pseudo):
<?php
//Start the session
session_start();
//Get the session data
$_SESSION['user'] = retrieveSessionDataFromDB($_SESSION['user']['unique_id']);
//Profit
?>
I would recommend using the built in session functions because you don't have to code all the session handling manually. By default the session state is stored in a file, but you can also change it e.g. to the database using session_set_save_handler.
I would absolutely use PHP Sessions, for a couple of reasons
First reason is that PHP Sessions are easily managed with native methods. There are also plenty of libraries that allow very robust Session management, such as Zend_Session
PHP Sessions are more scalable. Using MySQL as your data storage will likely be your biggest bottleneck once your application starts to grow. Storing sessions in memory will allow you to scale horizontally to compensate. Storing in the database could put more strain on your database than it needs.
Typically, though, it doesn't matter much for small applications, but if you plan to grow I would definitely use PHP Sessions.
Related
Is there a more contemporary alternative to PHP session or is PHP session still the main choice to store information? I read this: https://pasztor.at/blog/stop-using-php-sessions. I'm still learning PHP and frankly, I'm quite clueless.
Your first assumption is incorrect. PHP Sessions are not where you store data. Databases, files, Document stores, etc. are where you store your data.
Session "data" is simply the variables included in the $_SESSION array in serialized form. You can run serialize() and unserialize() on variables to gain some insight into what these look like.
In your script, once you have started a session using session_start(), when you add change or delete variables in $_SESSION, php serializes this and stores it for you.
Once a session exists, and a user makes another request that is identified as being the same user (having the same session id) which has typically passed to the client via a cookie, then upon issuing session_start(), PHP reads the serialized data in the session file, and unserializes it, and stores it back into $_SESSION.
By default, PHP will store the individual session data as files on the filesystem. For a small or medium size application, this is highly performant.
So to be clear, what people store in PHP sessions is basically variables read out of whatever other persistent storage you might have, so that you can avoid doing things like re-querying a database to get the name and user_id for a user who has already logged into your application.
It is not the master version of that data, nor the place through which you will update that data should it change. That will be the original database or mongodb collection.
The article you posted has a number of stated and unstated assumptions including:
Devops/Sysadmins just decide to reconfigure PHP applications to change the session handlers (misleading/false)
The deployment involves a load balancer (possibly)
The load balancer doesn't support or use sticky sessions
He then goes on into some detail as to several alternatives that allow for shared session handlers to solve the race conditions he describes
As you stated, you aren't clear yet what sessions actually are, or how they work or what they do for you. The important thing to know about PHP scripts is that they are tied to a single request and sessions are a way of not repeating expensive database reads. It's essentially variable cache for PHP to use (or not) when it suits your design.
At the point you have a cluster, as pointed out in the article people often store data into shared resources which can be a relational database, or any of many other backends which each have different properties that match their goals.
Again, in order to change the session handlers, there is typically code changes being made to implement the session handler functions required, and there are ways to code things that mitigate the issues brought up in the article you posted, for just about every persistence product that people use.
Last but not least, the problems described exist to whatever degree with pretty much any clustered serverside process and are not unique to PHP or its session mechanism.
Usually, that will depends on the use case and other requirements of your application and most of the time people will use PHP frameworks to handle sessions.
Take for example, for Yii 2 framework, the framework provides different session classes for implementing the different types of session storage. Take a look at here https://www.yiiframework.com/doc/guide/2.0/en/runtime-sessions-cookies.
Learning the different types of sessions available out there, allows you to be able to make decisions by weighing the pros and cons. You can also read here for more understanding https://www.phparch.com/2018/01/php-sessions-in-depth/
I'm developing a generic app on PHP that is dynamically customized for many clients.
I have the class client, where I load the style and preferences for the client.
My question is:
Is it a good practice to save that object in a session? (I think that is the best solution instead of creating the object in each page, that will need lots of mysql querys.
There are few things you need to consider while you deal with session.
You should not store vary large values in session.
i think this is not a problem in your case as preferences are usally small enough.
When you store object in session. you might not get realtime updates. as for example lets say same user is logged in using two separate browsers and/or machines and modify preferences in one. in this case other one will not have the updated customization. its not a big problem but depends on your requirements.
I don't see any other problem here. in fact its valid and good solution to store small values in session and avoid db queries.
if it's something that won't change, and will just result in constantly calling MySQL queries over and over then yes, that is a good idea.
MySQL queries (and functions in general) are memory/cpu intensive and can affect page load speeds for the PHP, so the less work you are causing it to do the better.
if the returned values are going to be changing constantly it would be better not to, but store what values you can in the session.
I think the session will die when client close the browser.
If you store it in cookie (Loaded client) ? it not good for security.
When you store mini data in session (Loaded server).that mean you are using some memory at server.
What happen at the time you have many client ?
So, the database connection should be destroy at the end of process for each page.
Don't worry to use it.
What's the best way to store temp data in PHP across page views? MySQL or server side cookies? Or something else I don't know about?
You could use the $_SESSION variable. I've seen people using it to keep session information such as cart contents, and generally to pass information from one page to another.
There's an extensive documentation on session variables at http://www.php.net/manual/en/ref.session.php .
I would advise against MySql in this case.
I prefer using PHP session for storing data on server side. For efficiency you can use memcached to save session values (default are saved on filesystem).
You can use $_SESSION like Clement suggested, but $_COOKIE may be appropriate also. Especially if you need to fetch the values client side. Here are some examples on how to use Cookies in PHP: http://www.w3schools.com/php/php_cookies.asp
Session variable is backed by a storage mechanism, that is, when the request finishes the session gets written by the session handler, by default this is to a file. On the next request it is pulled back from that file (or whatever else the session handler uses).
If you're reading and writing this data on every request, just stick with a the $_SESSION variables, the overhead of connecting, querying and updating a database will not be faster than the default $_SESSION.
You'll probably only ever want to use a database backed session if you are running multiple load-balanced servers and need to share the session data between them. In this case, if you find the overhead of the database sessions to be slowing down your site to a noticeable degree you might consider sticking memcached between your web server and the database.
Right now I'm stuck between using PHP's native session management, or creating my own (MySQL-based) session system, and I have a few questions regarding both.
Other than session fixation and session hijacking, what other concerns are there with using PHP's native session handling code? Both of these have easy fixes, but yet I keep seeing people writing their own systems to handle sessions so I'm wondering why.
Would a MySQL-based session handler be faster than PHP's native sessions? Assuming a standard (Not 'memory') table.
Are there any major downsides to using session_set_save_handler? I can make it fit my standards for the most part (Other than naming). Plus I personally like the idea of using $_SESSION['blah'] = 'blah' vs $session->assign('blah', 'blah'), or something to that extent.
Are there any good php session resources out there that I should take a look at? The last time I worked with sessions was 10 years ago, so my knowledge is a little stagnant. Google and Stackoverflow searches yield a lot of basic, obviously poorly written tutorials and examples (Store username + md5(password) in a cookie then create a session!), so I'm hoping someone here has some legitimate, higher-brow resources.
Regardless of my choice, I will be forcing a cookie-only approach. Is this wrong in any way? The sites that this code will power have average users, in an average security environment. I remember this being a huge problem the last time I used sessions, but the idea of using in-url sessions makes me extremely nervous.
The answer to 2) is - id depends.
Let me explain: in order for the session handler to function properly you really should implement some type of lock and unlock mechanism. MySQL conveniently have the functions to lock table and unclock table. If you don't implement table locking in session handler then you risk having race conditions in ajax-based requests. Believe me, you don't want those.
Read this detailed article that explains race condition in custom session handler :
Ok then, if you add LOCK TABLE and UNLOCK TABLE to every session call like you should, then the your custom session handler will become a bit slower.
One thing you can do to make it much faster is to use HEAP table to store session. That means data will be stored in RAM only and never written to disk. This will work blindingly fast but if server goes down, all session data is lost.
If you OK with that possibility of session being lost when server goes down, then you should instead use memcache as session handler. Memcache already has all necessary functions to be used a php session handler, all you need to do it install memcache server, install php's memcache extension and then add something like this to you php.ini
[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
;session.save_handler = files
session.save_handler = memcache
session.save_path="tcp://127.0.0.1:11215?persistent=1"
This will definetely be much faster than default file based session handler
The advantages of using MySQL as session handler is that you can write custom class that does other things, extra things when data is saved to session. For example, let's say you save an object the represents the USER into session. You can have a custom session handler to extract username, userid, avatar from that OBJECT and write them to MySQL SESSION table into their own dedicated columns, making it possible to easily show Who's online
If you don't need extra methods in your session handler then there is no reason to use MySQL to store session data
PHP application loses session information between requests. Since Stanford has multiple web servers, different requests may be directed to different servers, and session information is often lost as a result.
The web infrastructure at Stanford consists of multiple web servers which do not share session data with each other. For this reason, sessions may be lost between requests. Using MySQL effectively counteracts this problem, as all session data is directed to and from the database server rather than the web cluster. Storing sessions in a database also has the effect of added privacy and security, as accessing the database requires authentication. We suggest that all web developers at Stanford with access to MySQL use this method for session handling.
Referred from http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions
This may help you.
Most session implementations of languages’ standard libraries do only support the basic key-value association where the key is provided by the client (i.e. session ID) and the value is stored on the server side (i.e. session storage) and then associated to the client’s request.
Anything beyond that (especially security measures) are also beyond that essential session mechanism of a key-value association and needs be added. Especially because these security measures mostly come along with faults: How to determine the authenticity of a request of a certain session? By IP address? By user agent identification? Or both? Or no session authentication at all? This is always a trade-off between security and usability that the developer needs to deal with.
But if I would need to implement a session handler, I would not just look for pure speed but – depending on the requirements – also for reliability. Memcache might be fast but if the server crashed all session data is lost. In opposite to that, a database is more reliable but might have speed downsides opposed to memcache. But you won’t know until you test and benchmark it on your own. You could even use two different session handlers that handle different session reliability levels (unreliable in memcache and reliable in MySQL/files).
But it all depends on your requirements.
They are both great methods, there are some downsides to using MySQL which would be traffic levels in some cases could actually crash a server if done incorrectly or the load is just too high!
I recommend personally given that standard sessions are already handled properly to just use them and encrypted the data you do not want the hackers to see.
cookies are not safe to use without proper precaution. Unless you need "Remember me" then stick with sessions! :)
EDIT
Do not use MD5, it's poor encryption and decryptable... I recommend salting the data and encrypting it all together.
$salt = 'dsasda90742308408324708324832';
$password = sha1(sha1(md5('username').md5($salt));
This encryption will not be decrypted anytime soon, I would considered it impossible as of now.
I have a social network type app I have been working on for at least 2 years now, I need it to scale well so I have put a lot of effort into perfecting the code of this app. I use sessions very often to cache database results for a user when a user logs into the site I cache there userID number, username, urer status/role, photo URL, online status, last activity time, and several other things into session variables/array. Now I currently have 2 seperate servers to handle this site, 1 server for apache webserver and a seperate server for mysql. Now I am starting to use memcache in some areas to cut down on database load.
Now my sessions are stored on disk and I know some people use a database to store sessions data, for me it would seem that storing session data that I cached from mysql would kind of defeat the purpose if I were to switch to storingsessions in mysql. SO what am I missing here? Why do people choose to use a database for sessions?
Here are my ideas, using a database for sessions would make it easiar to store and access sessions across multiple servers, is this the main reason for using a database?
Also should I be using memcache to store temp variables instead of storing them into a session?
PHP has the ability to use memcached to store sessions.
That may just be the winning ticket for you.
Take a look at this google search.
One part of the Zend Server package is a session daemon.
Be careful using memcache for that purpose. Once the memory bucket is full, it starts throwing away stuff in a FIFO fashion.
Found this on slideshare about creating your own session server with php-cli.
The single best reason to store sessions in the database is so you can load-balance your website. That way it doesn't matter which server hands out the next page because they are all using the same database for storing their sessions.
Have a look at PHP's set_save_handler() for how to install a custom session handler. It takes about 30 lines to set one up that puts the session in the database, though that doesn't count the lines to make a decent database handler. :-) You will need to do:
ini_set('session.save_handler', 'user');
ini_set('session.auto_start', '0');
... although session.auto_start will need to be in your php.ini (and set to 0).
If the database access is going to be a bit expensive, there are some other things you can do to mitigate that. The obvious one is to have a DB server that is just for sessions. Another trick is to have it poke stuff into both memcache and the DB, so when it checks, if the memcache record is missing, it just falls back to the DB. You could get fancy with that, too, and split the session up so some of it is in memcache but the rest lives in the database. I think you'd need to put your own access functions on top of PHP's session API, though.
The main reason to store session data in a database is security because otherwise you have no way to validate it. You'd store the session ID along with the data in the database and match them to see if the session has been tampered with but you can't use the server's (apache) default session mechanism anymore.
For Storing variables in memcache instead of the session.. have you set up your database query cache? I'd have a look there instead first as it's far easier to deal with than with memcache.