i am working on PHP and i know how to manage the session. But my question is, session is related to language or web server. Who is responsible to execute the session?
You are responsible for session execute by starting the session with session_start().
By default session is stored in /tmp on a Linux/Unix system. You can change it with session_save_path() method.
Also take a look in php.ini for [Session] part, it should look like this
; Handler used to store/retrieve data.
; http://www.php.net/manual/en/session.configuration.php#ini.session.save-handler
session.save_handler = files
As You can see by default it is stored as file storage, it's recommended to move session to cache i.e. memcache.
EDIT:
Maybe this post can help You: https://security.stackexchange.com/a/19054
A session token is a unique identifier that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier—all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. Examples of the names that some programming languages use when naming their HTTP cookie include JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI), and ASPSESSIONID (ASP).
Sessions are a combination of two components, namely, a client-side session ID and server-side session data. well, practically it behaves like a cookie, 2 cookies which reply on each other. The Client-side can send a session ID to the server-side as a URL param, cookie, or even HTTP headers. The server then uses this session ID to find the matching session data to return to the requesting client.
so to answer your question straight up, a session is part of both the server and the client, which you maybe refer to as language. But PHP handles the execution.
additionally, You can tweak session behavior via the various session functions.
Session is generated by server but it is coupled with the language. So if you look into your browser resource you'll find your session id prefixed with the language you are using.
Related
PHP Superglobals behave in different ways and I'm never sure about which one to use.
When can the client (I'm not talking about hackers or security attacks, but "normal users") edit, create or access a Superglobal variable?
Even php.net documentation does not talk about this fact.
Basing on what I've learnt so far I can summarize them in this way:
superglobal read create edit
$_GET V V V
$_POST X V X
$_FILES X V X
$_SESSION ? X X
$_COOKIE V V V
I'm not talking about your PHP script which creates a SESSION variable when an user send a form or something like that, but I'm talking about the fact that anyone could add a fake form inside the DOM to POST anything or use a simple Chrome extension like EditThisCookie to read, create or edit any COOKIE.
So:
Is my table right? I'm not sure about some points and they are crucial for security reasons
Where should I store sensible data such as access tokens or user IDs?
I've always stored IDs inside a COOKIE because I can set its expire time, and then I figured out that anyone could fake them. If there's not a way to prevent it, I would be forced to use SESSION, with the problem that it expires together with the browser session (when an user closes its browser, he loses its login session).
Or sometimes I used POST method to verify that a call comes from a specific page, but then I realized that the client could read the content of that form and fake it from everywhere. Should I use SESSION for this purpose too?
Is my table right?
No.
With the exception of $_SESSION all of those superglobals contain data pulled from the request made by the client. The client can set the initial value (for a given run of the PHP program) for any of them.
The client can't read any of them. (They can read all the data sent by or stored in their browser and infer the data in any of those superglobals from it ($_SESSION still excepted), but they can't read the superglobals themselves).
The client can't edit any of them (other than by making a new request which would rerun the PHP program from the start).
$_SESSION contains data stored on the server. A particular session can be selected with the SESSION ID that is stored in a cookie and sent by the client.
anyone could add a fake form inside the DOM to POST anything or use a simple Chrome extension like EditThisCookie to read, create or edit any COOKIE.
Yes. Don't trust data from the client blindly. The client can send whatever data it wants in the cookies, query string or post body.
Or sometimes I used POST method to verify that a call comes from a specific page, but then I realized that the client could read the content of that form and fake it from everywhere. Should I use SESSION for this purpose too?
You probably shouldn't care.
(Tricking a third party into submitting fake data is another matter, but see this question).
Where should I store sensible data such as access tokens or user IDs?
Access tokens (providing they are tokens which are designed to give a particular user access to something and not (say) an API key that your server should use to access a third-party server) need to be stored on the client. The particular place depends on how you are going to use it. For the most part, a session ID is fine.
User Ids (assuming they are being used as evidence that the user is that user Id) need to be stored in such a way that they can't be edited to someone else's. That means either being stored on the server (in a session usually) or in a format that can't be altered (like an encrypted JWT on the client).
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.
Is it possible start Session with out using any server side scripting like PHP.
I want start SESSION with pure HTML/HTML5./Javascript.. ?
Thanks Advance. :)
The usual meaning of the term "session" in web development is "A bucket of information stored on the server that is linked to a specific user via a token". Since the definition requires a server to be involved, no you cannot achieve that without a server.
You can store the data in a session cookie (one without an explicit expiry time that will die when the browser is closed).
In modern browsers, you can store larger amounts of data using sessionStorage.
You could set a COOKIE with Javascript (http://www.w3schools.com/js/js_cookies.asp).
If you really want a PHP Session without PHP, that's impossible. A Cookie is the closest you'll get.
On the topic of Cookies, these are stored locally on the users system and can be edited. I do not reccomend using this method if you need good security. See this blog post explaining more on this matter:
http://www.nczonline.net/blog/2009/05/12/cookies-and-security/
No its not possible. What you use in PHP is the PHP session handler.
In javascript you can use cookies to store some small data.
I understand the $_SESSION thing and I use it, but what session_id really is and what does it give? I don't get it, can you give me a hand? Thank you.
Well you need a small lesson on web technology in general.
Protocol we are using, named HTTP, is stateless. Means it never keep track on requests. Even if you click several links on the site, each request would be fresh new, as though there was no previous ones. There is no way to distinguish requests from the same client.
Thus, if we want to distinguish clients, we have to "mark" them somehow. Assign some unique identifier and make them send it with each request. So your session id is that mark. When you start a session for the first time, a cookie is sent along with server's response. Good client always send all cookies back with every consecutive request. So, we can recognize that client.
Throw in a file on the server side, named after this session id, to store session data - and now you've got a session mechanism!
session_id() returns the value of the session cookie by the name returned from session_name(). session_id() is normally a very long hash that is unique to the client.
PHP could internally implement the setting of the client's cookie this way:
setcookie( session_name(), session_id() );
I recommend that you read the Session reference on php.net. You can get the session ID with session_id(). It's value is generated by PHP.
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