I need to pass an array from one function to another.
I tried with session variables.
$array;
$this->session->set_userdata('array',array);
$array = $this->session->userdata('array');
but it does not work for older arrangements 2KB.
I read that you can not spend such a long array, that session variables are stored in cookies on the browser and does not allow more than 2 or maximum 4KB according to the browser.
I tried to serialize also. Any ideas?
Switch sessions to database, then you can store larger amount of data. See http://www.codeigniter.com/user_guide/libraries/sessions.html#database-driver for details.
You have two option on this issue.
Don't store every data in session. Store somthing unique.
Explenation: if your database having all the user data and you are trying to store all the in session. Its worthless. Just store user id with session time So when ever you need and user data you can call the session user id and send request to database and get the user information..
Can use session tables which provided by Codeigniter.
I need to store data in a session and make it available for other users.
I thought about to store that data in an Session, generate a random Link, which user 1 can send to user 2. The Session should expire after 3 Month.
The session name is the random code I generate which is simluar to the code I send with POST to receive it on the Secretlink with $_GET.
Is this working in general or am I on the wrong track?
Can I store a Session even when the user 1 left the website or will the session be terminated?
I also need to set the session via jQuery, but I couldn't find anything about expiration time of a session.
I already did it with a cookie, but of course that's not working with user 2.
Sessions are actually files, stored on the server. PHP sets a cookie with the session id, named PHPSESSID. You can also use the PHPSESSID GET parameter, but you would have to change that in the server's PHP settings. Using the GET parameter, you could pass that link to another visitor to let him use the session. You would also have to extend the session expiration time.
However, I wouldn't recommend sharing sessions with GET parameters. It could be a security risk when you are storing personal data in those sessions. I recommend that you write a small script that stores data in a database and that can be accessed (for reading and writing) by requesting an url or any url with a special GET or POST parameter.
One last thing, sessions are never accessible from jQuery directly. You would have to write a small script that requests data on your server via AJAX.
A few questions before I start my project in Codeigniter
How long does Codeigniter store the data in a session table for a particular user. Is it as long as he is logged in?
How can I modify the schema of the sessions table, I mean modifying the datatypes of the already present schema.
Above question brings me to another one, can i change the Session table schema itself?
Can I put in multiple cookies on the user's browser through a single session ID.
How can I access the Session table through MYSQL console or is only accessible through the Codeigniter
When the user logs in to my website again, how are the cookies from my website stored during the user's previous login get available to me for reading. How can i read them?
I know this might have been asked in bits and peices before but I wanted to have a clear picture in mind before I start my project. Thanks in advance
Codeigniter actually uses cookies for their sessions and you set the expiry time in the config.php file. I am not really sure how long it stores the actual database info (It isn't that long) and it will rewrite a new entry for a user when they log back in. So it's not really recommended to store critical data in the session table itself that isn't stored elsewhere. As long as their cookie persists the information could be restored but if they delete the cookie then you'll lose that data. If you need to store something permanently on a user don't use the session table.
I have no idea why you'd want to change the data types of the already present schema and honestly that would very likely screw up the system being able to store that data anyway without extending the session library. This seems like a huge headache to me for no real value.
Answered 3 already, don't add to the schema, create a new table if you need to store more info.
As to 4, 5 and 6. Since CI uses cookies for it's sessions anything you store in the session is a cookie and will be there until it expires or the user deletes their cookies.
Save info to the session:
$this->session->set_userdata('some_key','some value for that key');
Retrieve it:
$data = $this->session->userdata('some_key');
Read more here: http://ellislab.com/codeigniter/user-guide/libraries/sessions.html
I have a e-commerce (PHP) system. And it is working now. I decided to allow non-members can order. I'm using session for userid. And i'm storing data in database. But how can i do it for non-members ?
Using Cookie or Session. I couldn't decide it. What is your offer ? Should i store all data in cookie ? Or in database ?
I would store all of the data in the session up until the final step of your order flow and then save the order and customer data to the database.
Cookies only allow around 4kb of data storage and while it is possible to use multiple cookies on a site to increase the total storage space, generally you would store data on the server and only store an identifier in the cookie to retrieve the data. This is how cookie based sessions work as well which is the default session handling type in PHP.
Storing data in a cookie requires that the user has cookies activated. Store the data in the session.
On an e-commerce site with no username/login to persist cart data, would it be better to use the PHP $_SESSION variable or a browser cookie to persist items in the shopping cart? I am leaning toward $_SESSION since cookies can be disabled, but would like to hear thoughts from you.
Thank you in advance for your consideration.
Neither
No large sites would dare store a user's cart in a session or cookie - that data is just to valuable.
What customers are buying, when they select items, how many they purchase, why they don't finish the checkout, etc.. are all very, very important to your business.
Use a database table to store this information and then link it to the user's session. That way you don't lose the information and you can go back and build statistics based on users carts or solve problems with your checkout process.
Log everything you can.
Database Schema
Below is a simplified example of how this might look at the database level.
user {
id
email
}
product {
id
name
price
}
cart {
id
product_id
user_id
quantity
timestamp (when was it created?)
expired (is this cart still active?)
}
You might also want to split the cart table out into more tables so you can track revisions to the cart.
Sessions
Normal PHP Sessions consist of two parts
The data (stored in a file on the server)
A unique identifier given to the user agent (browser)
Therefore, it's not $_SESSION vs $_COOKIE - it's $_SESSION + $_COOKIE = "session". However, there are ways you can modify this by using a single encrypted cookie which contains the data (and therefore you don't need an identifier to find the data). Another common approach is to store the data in memcached or a database instead of the filesystem so that multiple servers can access it.
What #Travesty3 is saying is that you can have two cookies - one for the session, and another that is either a "keep me logged in" cookie (which exists longer than the session cookie), or a copy of the data inside separate cookie.
As pointed out by Xeoncross, it is very important to store any possible information for analysis. So one should not entirely rely on sessions and cookies.
A possible approach is-
Use sessions if not logged in
If the user is not logged in, you can store and retrieve the cart items and wishlist items from session using $_SESSION in PHP
Use database when logged in
If the user is logged in then you can consider one of the two options -
Store the cart item or wishlist item in database alone
Store the cart item or wishlist item in database as well as in session (This will save some of your database queries)
When user logs in
When the user logs in, get all the cart items and wishlist items from the session and store it in the database.
This will make the data persistent even if the user logs out or changes the machine but till the user has not logged in, there is no way to store the information permanently so it will not be persistent.
Getting required data
Whenever you are trying to access cart or wishlist do the following check -
If the user is not logged in then look into session
If the user is logged in, query database if you are storing in the database alone, otherwise you can just look into sessions if you are keeping session updated along with the database
I would store it in a SESSION. My wish list is rather long, and I am afraid that it will not fit in the 4K storage that a COOKIE may occupy. It forces you set the session time out to a longer period.
note: there are some countries (like the Netherlands, where I am) that have very strict policies about cookies, and you may be forced by legislation to use Sessions.
Some points to help:
Cookies:
info is persisted untill the cookie expires (what can be configured by you);
tend to slow down the communication between server and client, since it has to be exchanged between the two in every request/response;
its an insecure form of storing data and easy to sniff;
they also have a limit to store data.
Session:
all information is persisted in the server, thus not been exchanged with the client.
because it is not shared across the network, its a bit more secure;
all info is lost when the session ends;
If you are hosting in a shared host, you may have problems with session ending in the middle of a operation due to a push on the resources by any of the sites hosted on the same server.
I would personally go with sessions, since I'm assuming to be a small/meddium auddience page. If it grows, you would be better with a simple DB structure to store this data, with a maintenance plan to get ridge of unnecessary data (eg: clients that choose some products but don't do the checkout).
You might consider using both.
The drawback with $_SESSION is that the session is cleared when the browser is closed.
Use sessions, but attempt to populate the $_SESSION data from a cookie, if it's available.
I would use a session. If a user has cookies disabled then the session won't be able to start as the session ID is stored on the user's machine in a cookie.
There are some settings you may want to look at in order to attempt to keep the sessions for longer.
Prevent the session cookie from being deleted when the user closes their browser by running session_set_cookie_params() with the lifetime parameter set. This function needs to run before session_start()
You may also want to extend how often sessions are cleared from the server by modifying the session garbage collection settings session.gc_probability, session.gc_divisor, session.gc_maxlifetime either in php.ini or using ini_set()
If you have other websites running on the server and you modify the above garbage collection settings you will need them set in php.ini so they apply to all websites, or if you are using ini_set() then you might also look at saving these sessions to a different directory than other websites by modifying session_save_path(). Again this is run before session_start(). This will prevent the garbage collection of other websites clearing up your extended sessions for one particular site.
I would also recommend setting the following session settings in php.ini session.entropy_file = /dev/urandom, session.entropy_length = 256, session.hash_function = sha512. That should give you a cryptographically strong session ID with an extremely tiny chance of collisions.
And make sure you have an SSL cert on your site to prevent man in the middle attacks against your session ID.
Obviously a user could still decide to manually clear all their cookies which will take the session ID cookie with it but that's a risk I'd be prepared to take. If I was halfway through a shopping cart system and hadn't checked out, I wouldn't go and clear my cookies. I still think sessions are better than just using plain cookies.
The data is secure enough so long as you are the only website that has access to your sessions directory and your session ID is strong. And by extending the server's session storage time your data can persist on the server.
There are further measures you could employ to make your sessions even stronger. Regenerate your session ID every 20 minutes, copying the data over. Also record session IDs against IP addresses in a database and check to see if a particular IP address attempts to send more than X number of session IDs in a given time to prevent someone trying to brute force a session ID.
You could also store the data in a database linked by the session ID, instead of in a session file on the server. However this is still reliant on a session ID which is stored in a cookie and could disappear at any time. The only way to truly be sure that a user doesn't lose their cart is by having them login first and storing in a database.