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.
Related
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.
I want to store a database table in a cookie (for example, to store items in a shopping cart for a user that is not logged in).
My problem is, say the table has a list of items where I need to store an ID and amount for each item.
What is a good data structure I could use for PHP to store the data in the cookie?
Cookie Can only store 4KB of session data.You can store the session data in the database or cache in the raw file at server. if you really wish to store the data at client side take a look on some of these javascript storage libraries pablotron , DojoStorage , localstrogage Firefox,Chrome,Safari,Internet Explorer 8+ 5 MB per domain.
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.
I'd like to know if there is any way to create session data that expires earlier than default session expire time in codeigniter?
For example, storing shopping cart indefinitely but everything else expires after 30 minutes.
Do I have to do it the hard way (deleting them manually)?
Thanks.
My opinion is that you have to use things the way they are designed. Sessions are meant to be a temporary storage as the user switches pages. If you want to store something indefinitely, store it in a database. Thats what databases are designed fore.
To identify the user, and his shopping card, you have to store a cookie with a ID on the users machine, or let the user login or register.
By using a database, and a login mechanism, the user can retrieve his shopping card also on an other location on a different machine.
Let the user delete his own shopping card, and use a cleanup mechanism for shopping cards older then a certain time (3 months, a year?)
The user's cart is usually best kept on the user's machine. Assuming a modern browser, you can use HTML5's localStorage to keep the cart data on the user (since it's not sensitive data, it's fine).
If you are supporting older browsers, you'll need to resort to cookies, but it's still not the server's job to remember which cart each user has.
I have created a registration/login system for my members area. Once the user has logged in I want to store a session variable that I can use to retrieve data associated to the user from the database.
Should I in encrypt the variable in any way? The data I want as a variable will either be the username or the id, which is best?
Should session ids be regenerated in anyway and when??
Data storage in session is considered to be "safe", so you dont need encrypt-decrypt it.
You should regenerate your session id after a successful login/logout. For security reasons, I would reccomend to ask the user for his password if he want's to perform a critical action (changing important data, deleting account or submit an order for example).
As AurimasL stated, you don't have to worry about session data on the server side. I reccomend this reading, if you are on a shared host, because then there are some security aspects: http://phpsec.org/projects/guide/5.html
Session IDs are stored like a cookie on the client's machine, and are passed back to the server for every single request. This is how PHP determines what information to load into a session once it receives the request.
Since sessions live on the server and not on the client, you only need to worry about session hijacking in regards to whether the information stored in them is secure or not. The answer to your question is no, I would not try to encrypt the information that is stored in session.
Just an add in the comments bellow,
Keep in mind that creating a sessions are expensive for your server app. Sometimes is a good idea stores the id in the session and other informations in cookies (informations that dont need security as the username).