I was used to naming my session variables the "normal" way, kinda like when I want to keep track of user details, I name them:
$_SESSION['username']
$_SESSION['email']
$_SESSION['id']
I am worried that they may be in conflict with other session data when I am browsing sites in the same browser, or will there not be any conflict at all(once I tried to simultaneously run two of my projects with the same session variables, residing in the same server, and obviously, things got real messy).
All of the session data is stored on the server. All the browser has is a cookie that references the session on the server. There can't be naming conflicts for this reason, and also because Cookies naming scope is domain based.
Consider setting them in a subarray related to your application:
$_SESSION['myapp']['username']
$_SESSION['myapp']['id']
That should significantly help avoid conflicts.
EDIT: I misread your question, Luca Matteis has your answer. My solution above would be to avoid your multiple apps on the same domain session conflict.
Related
Using the jQuery load function, i made it to where only the body of the website loads/changes. My header stays the same.
Rather than accessing your database, say, 50 times and requesting the same information on different pages, could I just risk a longer original loading time and include a php file that has everything i need stored in session variables for a user's account?
Are there any big security concerns for this or just any reason I am not seeing why this would be a bad idea?
I am finding myself accessing the same variables over and over again (like a unique id) on various php pages.
Sounds ok to me.
Consider if you need to synchronize and update the domain model (user account data) during access and want to resynch it to your client (view). What you describe however is common session behavior.
It sounds like you are doing it very low level, so you can go for this, without using a repository layer or dao or alike. Just read the date you need, be aware of concurrent access and ok.
For read only it is perfectly fine way of caching it.
It is a good idea imho. What else would you do besides a session, preferably via https.
Consider the security guidelines made here:
PHP Session Security
Yes, it is a bad idea:
Can a user alter the value of $_SESSION in PHP?
http://c2.com/cgi/wiki?GlobalVariablesAreBad
According to the documentation (http://ellislab.com/codeigniter/user-guide/libraries/sessions.html), the CodeIgniter session library has the following behavior:
"When a page is loaded, the session class will check to see if valid session data exists in the user's session cookie. If sessions data does not exist (or if it has expired) a new session will be created and saved in the cookie. If a session does exist, its information will be updated and the cookie will be updated. With each update, the session_id will be regenerated."
I think this behavior can be dangerous from a security point of view, because somebody could flood the site with requests and that way pollute the session store (which, in my case, is a mysql database). And my app is running on an ordinary web host..
Is there any easy solution to this which does not require too much additional coding? Maybe a library that could substitute for the one that ships with the core? I don't want to code it all myself because I think that would defend the purpose of using a framework.. and I actually don't want to use another PHP framework, since, for my specific requirements, CI is perfect as regards the freedom it gives you...
because somebody could flood the site with requests and that way pollute the session store
So? Then you just have a bunch of sessions in the db. This doesn't affect the validity of sessions. If there is a mechanism to delete old session based on space/time, then those sessions are gone and the former owners of those sessions will need to re-authenticate.
If you are worried about collisions, do a little research and you will find that any collision probability is a function of the underlying operating system and/or PHP itself, so CodeIgniter can't help you there.
Also, maybe disk space fills up but that is an operations/architecture problem, not a CodeIgniter problem and not a security issue in and of itself.
So as a engineer, I usually require a concert understanding to be able to work with something. I feel like I understand the basics of a session. I am wondering about the specifics and details there of.
What are the limitations of a session?
How can I manipulate a session? What can explicitly not be done to or with a session.
What data structures does PHP use to define and manage sessions?
Is a PHP session different from any other session in any significant way?
I understand that these questions are general, so if anyone can simply suggest a good resource I would be thankful. There is plenty of info out there, but it is either too basic or teaching to a specific topic.
Thank you for the help.
Sessions is a way for the server to recognize you so he sends to you a customized version of the page instead of sending always the same page for everybody.
To recognize you one way is he tells the browser to save in your computer a small file with a simple text, and when you visit the page again the server would ask the browser for that file, if the browser sends it, and it contains the expected content, the server can now know this is you again. That are cookies.
Another way to maintain a session, a part from cookies, is the server puts a special unique token for you in the url of all the links the page has. Whenever you browse the site all pages you visit will have that token, the server see it and know it's the token it made to you, so he knows it's you again.
So both with cookies or url-based sessions, the server will have to save info about the sessions opened, for example to store the $_SESSION variables you create in PHP, if you create such a variable the server will save it to a file which he will later identified by your cookie or token content and when you re-visit the page he will read that file and load the $_SESSION variables you create last time.
Here's a good resource: http://php.net/manual/en/book.session.php
What are the limitations of a session?
I don't really know what you mean by that. Limitations in what context?
How can I manipulate a session?
To manipulate values, just use the $_SESSION superglobal directly.
What can explicitly not be done to or with a session?
Again, without context, it's hard to understand what you mean. I guess an important point is that sessions are transient, so you can't explicitly store data you want to keep indefinitely.
What data structures does PHP use to define and manage sessions?
The filesystem.
Is a PHP session different from any other session in any significant way?
What is another session?
http://php.net is the best source for your questions
PHP session is a very nice way of having persistent information on your site for different users.
Check out the PHP session functions you can use.
You can view examples of how to use sessions at php.net.
A session is most commonly associated with user accounts. A user can log into your site, and you create a user session to keep track of their information and make sure they are allowed to be logged in.
The basic assumption is that a session is secure, because the server is aware of the sessions in progress. Utilizing sessions over HTTPS is a fairly secure way of keeping users logged into your site (without HTTPS you run the risk of session hijacking).
The other basic function is to have persistent data about a given user. So let's say you wanted to keep track if the user has submitted a form, you could do:
$_SESSION['form_submitted'] = TRUE;
And now you can check that global variable whenever you want to know if that specific user has submitted the form. So the session (in the same way a cookie is used) allows you to do really cool things that otherwise would not be possible.
I'm not quite sure what the purpose of session_names is..
Can someone please explain in what circumstances defining a name would be beneficial?
You have two sites on the same domain. (say, a blog and a forum)
They both run different pieces of software.
If they ran on the same session and used the same variables in $_SESSION, (say, user_id), they would conflict.
session_name lets you give each application a different session.
The default is - I think - PHPSESSID. If you have more than one application on the same host, they would share those sessions. So, you should set different session names for each application, so that there is no weird stuff happening.
If I have many settings that I want to store in a cookie, should I create multiple cookies with one option each, or one big cookie with multiple options in a serialized array or something?
Are there any pros/cons for either approach? What do most people do?
Well, mostly we do sessions -- send a single cookie with an identifier for the user, and store all the option values on the server. But if I really didn't want to do a session for some reason, I suppose I'd probably do the single cookie on account of it creating less network traffic if done properly.
A good reason to have separate cookies is so each one is independent of the others, that is to say, an individual cookie can then be expired without affecting other ones, which is not possible if you have everything stored in one big cookie.
Your options are:
PHP Sessions - No cookies required. Store all the data you want. Once the browser is closed or the session is closed new authentication is needed.
Persistent Sessions - One cookie with one value which is either the session key used to access stored sessions or used to access a database table with session information. You can store all the data you want and you have the benefit of not worrying about signing in all the time.
Cookie Only - Storing multiple values in a cookie is not always the best of ideas. Why? 1) Cookies are insecure and can be read by anyone. 2) keeping up with multiple cookies throughout your application can be a source of future bugs. 3) Depending on the client/browser to provide you with accurate data is never good. If you use cookies, make sure they have as light of a footprint as possible.
Big cookies only give you a tummy-ache. Eat Cake instead.
I'd prefer a serialized array....
Cookies are files stored on the client's machine or the server, so less is better.