I have my own Session class, which handles session actions. I wanted to make a mechanism, that the session starts only when it is needed - if no session variables are set, system does not create it.
So that's the code (simplified):
class Session
{
public function __construct()
{
}
protected function startSession($onlyIfExists = false)
{
if (session_id() == '')
{
if ($onlyIfExists && !isset($_COOKIE[session_name()]))
return;
#session_start();
}
}
public function setVar($id, $value)
{
$this->startSession();
$_SESSION[$id] = $value;
}
public function getVar($id)
{
$this->startSession(true); //starts session only if the session-id cookie exists (if the session was already started for this user)
if (isset($_SESSION) && array_key_exists($id, $_SESSION))
return $_SESSION[$id];
else return NULL;
}
}
And then I just always have to use this class object to get/set session variables, e.g.:
$session = new Session();
$session->getVar('test'); //does not start session at the first time
$session->setVar('test', 1); //starts session; after refreshing the page the above line does start session (cookie exists) and the value=1 is returned
Is it a good solution? Do you see any potential drawbacks, vulnerabilities? Or maybe it is a standard to start session each time?
Because in my application any session variables are created only after authorization, so I don't need session for 99.999% of users.
Thank you in advance.
Vulnerabilities: none, I guess. Pretty easy code, not much to go wrong.
Drawbacks: except for more code, none, really.
Advantanges: only in very highly used systems with a few authorized users. Really, starting a session is not that big of a deal, compared to things like Database queries and content compiling. Usually, I would not see a need to optimize this. Just start a session every time, or just on the relevant pages (e.g. if you have a few backend pages that do require auth, just start the session there). Except, of course, you deal with thousands of users per second. I measured a simple session_start() to take about 0.1ms.
Improvements: as zerkms suggests below, starting the session if the cookie exists, or the site wants to write to the session would be the easiest and bulletproof way to manage this and not spawn useless sessions.
Related
I Know A PHPSESSID in the server how can i read a session variable that is set to a PHPSESSID ( i don't want to use $_SESSION because i don't want start session in this thread ) i only want read session data with using PHPSESSID ??
PHP :
<?php
namespace MyApp;
class readSession extends \Thread {
private $sess_id,$data_name;
public function __construct($SESSID,$data_name){
$this->sess_id = $SESSID;
$this->data_name = $data_name;
}
public function run(){
$data = $this->readSession($this->sess_id,$this->data_name);
}
private function readSession($SESSID,$data_name){
session_id($SESSID);
session_start();
$temp = $_SESSION[$data_name];
var_dump($_SESSION);
session_destroy();
return $temp;
}
}
i write this code to read users session's data but it remove the users session data
First of all, reading another user's session data is a horrible idea. If you need to have shared access to that data - don't store it in the session.
Secondly, reading another doing it via session_start() with the same session ID is an even worse idea - that way you are effectively acting as that user. There's no easy/reliable way to read session data without intercepting it, but that's not by accident, it's exactly because you shouldn't do it.
That being said, don't call session_destroy() and the user's data won't be removed ... destroy means destroy. If you're looking for a way to just close a session, that's session_write_close().
I just want to know if I am able to hand over session variables from Laravel to my custom code. What I mean is: I want to handle log-in through Laravel and pass it to my profile section which is not in Laravel. Most of the routes are handled by a .htaccess file. The goal is to just login with Laravel auth and save that to $_SESSION['user'] var and redirect to /profile. Somehow I don't get that. The session name is the same in both, in Laravel's session.php's cookie name and my custom code's constant. Is there any other factor I should consider ?
Okay here's the code:
namespace Services\Session;
class OldSessionAuth
{
protected $auth;
function __construct()
{
$this->auth = \Auth::user();
}
public function setSession()
{
$_SESSION['user'] = $this->auth->toArray();
$_SESSION['auth'] = 'TRUE';
return true;
}
public function destroy()
{
session_destroy();
session_unset();
}
}
So, this is sort of my Session services, which is initialized only if it passes the Auth from the controller, Now I think I don't need to do that. so I skiped it, Basic Stuffs (Auth::Check()) really. So, I'd just do this in my login method.
$old = new Services\Session\OldSessionAuth();
$old->setSession();
return Redirect::to('/');
The home page is controlled by my custom made MVC and I want to grab the session, which in this case I can't. It shows Array(). There is no session manipulation when retrieving the session.
Laravel already has a pretty good session abstraction so I don't think you needed to use session_start(), $_SESSION etc directly. Sharing an session across two applications is a bit tricky. If you are tied to using the cookie approach, then you have to make sure that the session driver in use is the cookie one. You would also need to ensure that the restrictions on the cookie aren't such that your other application isn't being sent them by the user's browser.
By default, PHP will use a file cookie driver. In this case, what you would have to do in your other application is to read the "PHPSESSID" cookie, set the session ID using session_id() to this and only then would you have access to the session data using the $_SESSION variable in the other application.
This is all pretty hacky though. I would recommend that if you need to share sessions that you make use of a database session driver instead. This way, you are able to share arbitrary session data across applications using a standard interface. In this case, you would just read the "laravel_session" cookie instead to be able to look up the session in the database. There would be many hidden pitfalls if you then wanted to also modify this data from the other application as well though.
With the use of static variables and the singleton pattern, I thought that it would be easy enough to create a simple shopping cart that remembered what items where in the cart when another page was loaded.
I am having a problem of the shopping cart not remembering what was already in it when the page is refreshed.
Is there a problem with my code below or should I just use globals or a mysql database.
What is the best way to go about storing state..
<?php
//create a singleton class
class shoppingCart {
private static $_shoppingCartItems = array();
private static $_instance = null;
private function __construct(){
}
public static function getInstance(){
if(self::$_instance == null)
self::$_instance = new shoppingCart();
return self::$_instance;
}
public function add(ShoppingItem $item){
$this->_shoppingCartItems[] = $item;
}
public function cartCount(){
return count($this->_shoppingCartItems);
}
}
?>
Implementation
$item = new shoppingItem();
$shoppingCart = shoppingCart::getInstance();
$shoppingCart->add($item);
$shoppingCart->add($item);
//should increment by 2 on each page load but it doesn't
echo $shoppingCart->cartCount();
Static class members (or any other variables for that matter) are not preserved across different requests. Never.
Sessions to the rescue
The only exception to this is $_SESSION; which is a special mechanism to allow for just that.
Star the session with session_start() at the top of your script.
You can now use $_SESSION like a regular array to store and retrieve information. A session belongs to a single user, it is not a means of sharing data across all your users.
Have a look here for an introduction.
Silence
You must not output anything before session_start() is called. That is to say, <?php must be the exact first thing in a PHP script that wishes to use sessions. Further, there must be no echo statements or any other output generating functions between <?php and session_start().
Output Buffering
If you really must generate output before starting the session, you can use output buffering.
Notes
$_SESSION is forgetful. After a certain time of inactivity on the user's side, the data will be deleted.
If you get the following error message, you violated the above guidelines. Another possibility is that your script has a BOM (Unicode byte order mark). If so, remove it.
Warning: session_start(): Cannot send session cookie - headers already
sent by (output started at
The reason this happens is due to the way PHP handles output: It tries to get the output as fast as possible to the user. However, the HTTP protocol transmits certain control data (cookies, which session belongs to you etc), called "headers" before all the output ("body") of the response. As soon as you output anything, the headers need to get sent - unless you use output buffering that is.
I think I can see your thought pattern there but what you're trying to do is wrong in many ways.
1. Singleton is NOT a pattern, it's an antipattern
The Singleton is an anti-pattern and should be avoided at all costs. See this great answer by Gordon for the why.
2. HTTP is a stateless protocol.
Nothing you do in PHP alone will help you to preserve state across two requests. Your $shoppingCart is created from the scratch for each request, in fact, your whole application is. You should NOT try to persist data in objects instead you should recreate state after every request, by fetching the respective data from somewhere else. In your example probably from some sort of database nosql or sql.
3. Sessions
You can persist user specific data in the superglobal $_SESSION, but in most cases I advice against it. Your user session should hold authentication and user data but you should avoid storing all kinds data relevant for your business logic in there.
PHP is not an application server. It will not automatically persist your "application" state between requests. You have to do that yourself via $_SESSION, cookies, and/or your own private methods.
Unless you take steps to preserve data, the state of the application is wiped when the HTTP request that invoked the script(s) is ended.
I've got a problem with Zend_Session. I need to know, if the Session for this user was initially started the first time or if it was just updated in the current request.
I need to know that for statistics. If the session was initialized (meaning the user visits my app for the first time) I want to store the referer of the request in some db-table. This of course I only want to do for the first request within this session.
The manual talks about the methods Zend_Session::isStarted() and Zend_Session::sessionExists(). But it seems that both methods only work for within the current request (meaning it returns true if I use Zend_Session::start() somewhere in my app).
My approach was the following:
I tried to override Zend_Session::start() to insert the statistic-data into my db-table.
// Somewhere in my bootstrap:
My_Session::start();
// This is my class (eased up)
class My_Session extends Zend_Session
{
public static function start($options)
{
parent::start($options);
if(/* Here I need the condition to test, if it was the initial session-starting... */)
{
$table = new Zend_Db_Table(array('name' => 'referer'));
$row = $table->createRow();
$row->url = $_SERVER['HTTP_REFERRER'];
$row->ip = $_SERVER['REMOTE_ADDR'];
// ... some columns ...
$row->save();
}
}
}
Anybody has any idea?
I need to know, if the Session for this user was initially started the first time or if it was just updated in the current request.
Not a problem:
Zend_Session::start();
$my_logger = new Zend_Session_Namespace('my_logger');
if(isset($my_logger->has_already_visited_app) && $my_logger->has_already_visited_app) {
// this is not the first request
} else {
// this is the first request, do something here
// make sure to add the following
$my_logger->has_already_visited_app = true;
}
I was hoping someone could help me with a question I've come up on.
I have a Session object that handles storage of general session data, I also have a Authentication object which validates a users credentials.
Initially I passed the desired Authentication class name to my Session object then had a login method that created an instance of the Authentication object and validate the credentials. I stored the result of this validation in a Session variable and made it available via a getter. The user data was also stored in the Session for later use. In addition to all this, I have a logout method, which removes the user data from the Session and thus logging the user out.
My question is what role should the Session object play in users logging into their account?
And what other ways might one suggest I go about handling user login, as it stands right now I feel as though I'm getting too much wrapped up in my Session object.
Simply calling your authenticate method should trigger logic within Auth to store the proper data in the session (or some other data store) and Auth should also be used exclusively to retreive/revoke this info. So using the example form your comment it might be:
class Auth {
public static function authenticate($identity, $pass)
{
// do lookup to match identity/pass if its good then
/* assume $auth is an array with the username/email or
whatever data you need to store as part of authentication */
Session::set('auth', $auth);
return true;
// if auth failed then
Session::set('auth', array('user'=>'anonymous'));
return false;
}
public function isAuthenticated()
{
$auth = Session::get('auth');
if(!$auth)
{
return false;
}
return (isset($auth['user']) && $auth['user'] !== 'anonymous');
}
}
[...] as it stands right now I feel as
though I'm getting too much wrapped up
in my Session object.
And id agree. Idelaly for authentication/credentials you shoudl only be interacting with the Auth/Acl object(s). They would then utilize the session as stateful store... but you shouldnt care that its even stored in session. The code utilizng the Auth/Acl object(s) should be completely unaware of this fact.
For example:
//Bad
if($session->get('authenticated', 'auth'))
{
// do stuff
}
// also bad
if(isset($_SESSION['authenticated']))
{
// do stuff
}
//Good
if($auth->isAuthenticated())
{
// do stuff
}
// inside $auth class it might look like this
public function isAuthenticated()
{
$store = $this->getSotrage(); // assume this returns the $_SESSION['auth']
return isset($store['authenticated']);
}
The session is a good place for holding user data that you want to have managed in some sort of state across various pages or if you need a fast accessible way to get at it without hitting the database. It is a bad idea to keep secure information (re: passwords/etc) in the session, but rapid access information like username, name, email address, preferences, etc is all good data to put in the session. Try to keep it simple though.
Keep in mind though, that the session (or related cookie) should only ever be used for identification. It should not be used for authentication.
Authentication object is a good method. Make sure that it only holds secure information as long as it needs to and that it has all the necessary functions available to keep sensitive data protected.