To my amusement, I understand that one can call session functions in CLI. The way I understand it sessions make sense when the script is running in a response to an HTTP request (e.g. inside a WebServer). Insights ?
You probably want to access a session storage via CLI, and the easiest way is to set the session id, start the session and read from $_SESSION, instead of adding a lot of own code to fetch and parse the serialized data. You won't get the session id via cookie, POST or GET data, though. You have to pass it somehow. Also, you won't benefit from a created cookie when the session is started on CLI.
Related
I'm creating a client for protocol running over TCP/IP sockets,the protocol is request/respond but unlike HTTP, any party can initiate the request and get back respond.
The protocol is session oriented and passes state between requests in its header fields. So I would like to build upon PHP native sessions management to manage sessions and avoid having to re-invent the wheel.
But PHP sessions were build with http protocol in mind and assumes client capabilities related to sessions handling. For example
session_start();
The above line sends a session cookie to the browser or in case session.use_cookies='0' is set sends url parameter.
The question is now, is there way PHP can be forced to use session id given in the code at run time or retrieved from other storage locations to get current session data.
something like this.
//start session in index.php
session_start();
// somewhere in other pages
set_active_session_id('47f6ac750'); // magical function
$name = $_SESSION['name'] // works as normal
So, in other words, I want to use php sessions outside HTTP protocol.To be precise, on the CLI.
session_id() can be used to set the session ID. And it does it before the session is started, which will save you a ton of headaches.
I just hope you're only doing this for educational purposes, because it sounds horrible.
the question is really simple, but i searched it many different ways and the results were not related to my question.
so if i have a session variable in a php file if i open an html page after that and then a php file again, will i be able to retrieve the data ? or do they all have to be adjacent?
I tried php->html->php but i couldn't get the variables on the other side. maybe Im doing something wrong.
Thanks in advance
Not 100% sure what you mean, but if by "open" you mean in the browser, the calls do not need to be adjacent. You just need to do a session_start() in every PHP script in which you want to use session data.
Adjacency is not something that is really relevant for this question.
in PHP way of things, sessions are essentially files that contain serialized data on the server. The browser that called a script containing session_start() call receives a special token that identifies the session on the server, and it is normally (though not necessarily) stored as a cookie.
This effectively means that any php script that uses session_start() and receives a session id (via cookie or otherwise) will read and could use session data, unless it was removed from the server file system between the calls, or the session has expired (frankly, I'm not sure whether PHP removes the expired sessions on the server side).
Accessing anything outside of this model with the browser (html page, or even other sites) will not affect it in any way, unless these actions change or remove session id.
yes...session variable can survive php->html->php.
But on every php page ...very first line should be session_start()
This easy way (I guess): Set a cookie storing the session ID on the first php page. This way, every other php page can access the session ID and use it to restore the stored data, not matter how many (even foreign) pages were in between.
I'm using JS Objects to sort and filter a table but I need to store the original table data in case the user wants to return to it. I'm just wondering if there's an easy way to pass the object's data to a PHP session var, via AJAX, and retain stuff like the key/value relationships without doing a lot of heavy lifting.
Build a JSON-string of the object and store this string.
JSON.stringify
It's not possible.
On the client side, the session is identified by a cookie. The session ID is all you've got.
On the server, the session data is stored in a binary file, one file per session (typical scenario).
So you can't touch the contents from the session from the browser without help from the server.
And second: it's not "light". In an app I've been working on, modern computer and virtually no load yet, loading the session seem to be taking around 250ms, 10 times longer than the response time for the whole page when starting from scratch.
In summary:
you cannot touch session variables without writing a script on the server that handles the data
It's not "light".
does any body have any info/links as to how to integrate a cookie based session system? i've used file/mysql, and am currently using memcached. i wanted to play with apc sessions, but thought i'd give a go at cookies, only i don't know much about it.
i imagine i'd have to write my own session handler class?
In PHP session data is usually stored in a file. The only thing stored in the cookie is a session identifier. When sessions are enabled and a valid session cookie is found, PHP loads the users session data from the file into a super global called funnily enough SESSION.
Basic sessions are started using session_start(); called before any text is sent to the browser. then items are added to or removed from the session object using simple array indexing eg.
$_SESSION['favcolour'] = 'blue';
later...
$favcolour = $_SESSION['favcolour'];
basic cookie only sessions (no local storage) can be created with a call to
set_cookie('favcolour','blue'[,other params]);
before any text is sent to the browser, then retrieved from the cookie superglobal
$favcolour = $_COOKIE['favcolour'];
you don't need to call session_start() if doing cookie only sessions.
the optional [,other params] are more advanced and can be read about here http://www.php.net/manual/en/function.setcookie.php
Sessions can become a very complex discussion, I'd suggest doing some light work in them and then expand your knowledge.
DC
all you ever wanted to know about PHP sessions
http://www.php.net/manual/en/book.session.php
DC
To reuse PHP's session handling code you will need to add a write handler using session_set_save_handler and then do exactly nothing in that handler. That's because its called after the output to the browser is closed therefore you cannot send anything to the browser.
Before writing non header data to the browser use the set_cookie functions and store the contents of the $_SESSION array (after serialising and encrypting) into a cookie. when the applications start you can read the cookie unserialise it and put it into the $_SESSION array.
That's a quick hint at what to do as I have never done it, I prefer to write all my own cookie code. There may be some gotcha's but its not hard a few tests should find any gotcha's.
DC
I have an API that is dependent on certain state information between requests. As an easy first version of the code, I am simply using PHP session's to store the state information instead of something more advanced (APC, memcache, DB). Throughout my initial testing in a web browser, everything worked perfectly. However, it seems that when clients try to connect through non-browser methods such as Curl or wget, the state information is not being preserved.
Will a PHP session only be created if a browser is requesting the page? I am explicitly starting the session with session_start() as well as naming it before hand with session_name().
An added note. I learned that one of the major problems I was having was that I was naming the session instead of setting the session id via session_id($id); My intention in using session_name() was to retrieve the same session that was previously created, and the correct way to do this is by setting the session_id not the session_name.
It seems that session information will be persisted on the server as noted below (THANK YOU). But to keep this you must pass the session id, or, as in my case, any other id that would uniquely identify the user. Use this id as the session_id and your sessions will function as expected.
Session Cookies
Remember that HTTP is stateless, so sessions are tracked on your server, but the client has to identify itself with each request. When you declare session_start(), your browser is usually setting a cookie (the "PHP Session Id"), and then identifying itself by sending the cookie value with each request. When a script is called using a request with a session value, then the session_start() function will try to look up the session. To prove this to yourself, notice that sessions die when you clear your cookies.. many will die even as soon as you quit the browser, if the cookie is a "session" cookie (a temporary one). You mentioned that you're naming the session.. take a look in your browser cookies and see if you can find a cookie with the same name.
All of this is to say that cookies are playing an active role in your sessions, so if the client doesn't support cookies, then you can't do a session the way you're currently doing it.. at least not for those alternative clients. A session will be created on the server; the question is whether or not the client is participating.
If cookies aren't an option for your client, you're going to have to find another way to pass a session id to the server. This can be done in the query string, for example, although it's a considered a bit less private to send a session id in this way.
mysite.com?PHPSESSID=10alksdjfq9e
How do to this specifically may vary with your version of PHP, but it's basically just a configuration. If the proper runtime options are set, PHP will transparently add the session id as a query parameter to links on the page (same-source only, of course). You can find the specifics for setting that up on the PHP website.
Sidenote: Years ago, this was a common problem when attempting to implement a session. Cookies were newer and many people were turning off the cookie support in their browsers because of purported security concerns.
Sidenote: #Uberfuzzy makes a good point- Using sessions with curl or wget is actually possible. The problem is that it's less automatic. A user might dump header values into a file and use the values on future requests. curl has some "cookie awareness" flags, which allow you to handle this more easily, but you still must explicitly do it. Then again, you could use this to your advantage. If curl is available on your alternative client, then you can plausibly make the call yourself, using the cookie awareness flags. Refer to the curl manual.
If you call session_start(), then a session will be created if the client isn't in an existing one. If the client doesn't support (or is configured to ignore) the cookies or querystring mechanism used to maintain the session, a new session will be created on every request.
This may bloat your session storage mechanism with unused sessions.
It might be a better idea to only call session_start() when you have something to store in the session (e.g. user login, or something else that robots aren't likely to do), if you feel this is likely to be a problem.
Will a PHP session only be created if a browser is requesting the page?
Short answer: Yes. Sessions were created specifically to solve the HTTP stateless problem by leveraging browser features. APC, memcached, DB, etc. don't matter. Those are just storage methods for the session, and will suffer from the same problem.
Longer answer: The concept of sessions were created to account for the fact that HTTP is a stateless protocol, and it turns out that state's pretty important for a wide variety of software applications.
The most common way of implementing sessions is with cookies. PHP sends the session ID in a cookie, and the browser sends the cookie with the session ID back. This ID is used on the server to find whatever information you've stored in the session. PHP has the capacity to include and read a session ID at the end of a URLs, but this assumes that users will navigate to pages on your site/application by clicking links that include a generated session ID.
In your specific case, it is possible to use cookies with curl (and possibly wget). Curl is a web browser, just one without a GUI. If it's the command line curl program you're using (as opposed to the C library, PHP extension,etc.) read up on the following options
-b/--cookie
-c/--cookie-jar
-j/--junk-session-cookies