I was hoping someone, could give some information on Cookies and Codeigniter, I have read there user guide on them so I have an understanding of how to set them, etc. What I want to know is how do I use for example if you look at the BBC website, you can drag and drop the boxes and it will remember where you placed them with out the need for you to sign up or login in etc, so I assume it is being stored in the the cookie.
On my site, I have a menu system that allows the user to choose the content that features on 'their' page, now I don't want them to have to sign up or log in so I assume I could somehow store the content they requested in the cookie? Is this possible? Currently they click a link and the relevant content is pulled from the database using the ID in the URL and the ID in the database a match. Do I just save each ID that is requested? And if so how?
Thanks
The fact that you're using CodeIgniter doesn't matter, as you can set cookie information pretty easily with any platform you use. CodeIgniter simply provides wrapper functions for cookies to make them easier to deal with. If you know how to use CI's cookie helper, then you should have no problem making this work.
The most reliable solution would be to use a cookie that holds a unique id for that user. That unique id matches a database record that contains the settings for the user. By only saving the unique id in the cookie, you avoid having to read and write to the cookie when settings change. If you add new features to your site that need their own settings, you won't have to touch the cookie, you'll just add the new settings values to the db. Additionally, you don't want to expose settings information in your cookie, which may allow someone to edit the contents of the cookie to attempt a SQL injection or some other attack.
You can create more than one cookie for your site, so I would make new cookie for the unique id to match to the user settings. When a user visits your site, load the CI cookie helper, then use CI's get_cookie('unique_cookie') helper to find the cookie. The cookie name 'unique_cookie' is what you're using as the name of the cookie that contains the user's unique id.
If get_cookie() returns false, then the user doesn't have the cookie, so he's probably visiting for the first time or he deleted the cookie. You have to create a new cookie using set_cookie($cookie_array). The set_cookie() method takes an associative array as an argument. That array contains the values for the cookie, one of which is 'name' which you will set to 'unique_cookie', and 'value' will be a unique id (use the CI String helper's random_string() method to create a unique id). While you're setting the cookie, you also want to create a db record with that unique id the contains the default settings values.
While the user is on your site, create a session object (using CI's session library) that holds on to the unique id so when the user changes settings during the session you can match the session's unique id value to the db record so you can make updates to that record without having to keep touching the cookie. For any controller actions that may need to get or set settings, you can use the session tools to get the unique id. You should only need to touch the cookie when the user first enters your site and a session object has not been created yet.
Related
I ned to set a session per every user, so when the user log ou from his account and login again in another account the old session will not be shown but the new that related to his new account will be shown
I am using the normal method in laravel to do it
Session::put('key', 'value');
But the problem as explained is that the session will br shown in all user using this computer
Session ids are supposed to be non-guessable. You're going to have to resolve (attempted) duplicates serverside. If you search through every existing session for a match then your not going to be able to scale this / its going to be very slow. That means you need an access path to the session data based on the username AS WELL AS the session id.
There are lots of solutions to this. I don't think any of them are exposed directly in Laravel.
You need to deal with maintaining the mapping directly in the session management - so you will need a custom session handler. The session handler deals with serialized data - so you need to think about how the username is resolved within the session handler. You could put it in the session and deserialize the data again the handler, or read the value from a global variable. Or you could write a prototytype of the session into a database with the sessionid as the primary key and the username as an indexed lookup before the session close handler is called.
Another approach would be to store the session as the username rather than using the session id. You still need to protect the username though and avoid session fixation, hence you would need to explicity generate the session id using a mechansim where only you can recover the username from it, e.g.
$data=array($username, openssl_random_pseudo_bytes(16));
$sessionid = encrypt(serialize($data), $your_secret_key);
(You still need to write your own session handler for this).
I'm trying to build an orderform which others can use within an Iframe on their website. Later I want to add this form to facebook.
My current form uses a session to bind the ordered products to the user, but if I disable third party cookies in Internet Explorer I can't order anything. The session ID is changing.
During last steps I ask the user to login and bind an email address to the current session.
I prefer to keep using sessions, so when someone leaves my page, the ordered items are still in their chart. What is best approach to still use sessions inside my iframe?
Thanks for everyones help...
A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.
Sessions: Introduction
So this means that if cookies are disabled, you need to propagate a session id into the URL. For example:
Checkout
Now the session id will be passed along even if the user has cookies disabled. It is up to you save the users cart into a database or something for when they completely leave your website. Afaik, sessions are always completely destroyed when a user leaves.
More info on passing the session id can be found here: Passing the Session ID
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'm developing a web application using Codeigniter. When a user authenticates with my site I'm currently storing their 'user-identifier' in my session cookie (which I have enabled encryption on). Several of my model classes use the value in 'user-identifier' parameter of the session/cookie to make changes to properties of user accounts.
My concern is that I'm wondering if it's possible for someone to take a valid codeigniter-session cookie with a user-identifier that I've set, change the user-identifier's value to the value of a different user, and make changes to another user's account. Would codeigniter/php sessions create an error if someone attempted to change a property of a session cookie?
Open your /application/config/config.php, locate "sess_use_database" and change it to "TRUE" if you haven't already. This way all session variables will be stored in a database table and session cookie will only contain session id string.
For added security, you can also change "sess_match_ip" to TRUE. This way if someone steals your user's cookie and tries to pass it as their own, session will be destroyed.
"if
it's possible to take a
valid codeigniter-session cookie
change the user-identifier's value to
the value of a different user, and
make changes to another user's
account."
My answer is not really CI related, so please bear that in mind.
When you auth the user "username1" what should be sent back to the client, for auth purposes, should be a hash that the server correlates to that user. All communication between the client and the server will rely on that hash.
The server will generate a unique hash per user and the hash should have a short time to live. Can someone capture a hash and pass as that user? Certainly. That's why you should also check for the user's Agent and IP to check if they match the hash in order to prevent session hijacking.
NEVER DO THIS:
If seen some new developers storing the username in a cookie and reliing on that client sent variable to update their databases. Never do this. Do not ever, ever trust the client. When the server gets the client's hash it should check if it belongs to an authenticated user and grab the user_id (variable to update the user data) from the server. NEVER from the client.
I'm not sure what your "user identifier" is exactly. The general rule is, don't store anything in the session cookie but the session ID. Store everything else (like a user ID) internally on server side, and retrieve it using the session ID.
If the user changes the session ID (which is a random string), a new session will start. The idea behind the session ID is that it's impossible to guess other user's IDs - that's why it's random, and so long.
I am building a website in which the user can select what list items they see in their navigation menu, my idea is to store the menu items that the user selects in a cookie as this will stop the need for the user to be registered member on the website, is it possible to store realtime data in a cookie and how would I do this? For more information the navigation options are built from a mysql result, the then clicks a link and that link is added to a different list, if they click it again it is deleted, I need to add/remove these items from the cookie as the user add/removes it from there list.
i would use the cookie only to identify the user and do all of your menu option saving in MySql.
Grab the user id from the cookie and query the db for the menu_options and display them.
Either way, storing the data in a cookie or in the database, when the cookie expires, so does (effectively) the user. Plus people delete cookies all the time using cleaners like Adware and CCleaner. I do this about once a week. Cookie = Gone.
This is a bad idea.
The number of cookies a browser can store is not defined (however there is a hard limit for most browsers). RFC 2109 suggests at least 20 cookies per host and a min cookie size of 4k. Certainly the latter is adhered to by most browsers.
You're also going to have to replicate all the features of session management without the nicety of having server-side state. You do not want the kind of pain going down this route will cause you. Keep your session data server-side.
There is no requirement for a user to 'log-in' to have a session. You just need to assign them an automatic identity in a persistent cookie (the replace that if they ever do sign in). And map the session back to a more long term storage when the user changes the config.
C.