On my webpage I'm using a cookie that's set to 1 if they're admin
0 if they're not
so admins can have access to certain features,
how hard would it be for somebody to make a 0 into a 1 in their local cookie if they wanted to?
Cookies live on the client-side, so of course they are editable. Like everything else that comes from the client, cookies cannot be assumed secure, ever. It would be very easy for someone to make themself an admin using your design.
Don't be lazy; store the privileges on the server side and only on the server side.
It's actually pretty easy to edit a cookie. Extensions such as chrome edit this cookie allow for it to be done without even leaving the browser.
I use this for simple things like web tracking on news paper sites that limit the amount of articles you can view. I reset the cookie count and voila, I am able to view more articles.
google edit this cookie if you want to demo it and apply it to your site.
Editing a cookie is easy.
But is this what you really meant?
Session variables are stored on the server and thus cannot be modified by the client. The client only stores an ID that refers to the session.
Related
In my login code on my website, if the password & username are correct, I set a cookie to keep the user logged in.
I just heard from a user that he doesn't accept cookies automatically through his browser, and that that prevents him from logging in. That rhe cookie is not set.
Is there an easy way to counter that?
Tell me if you need the code I use.
It is possible to get this to work but often a real pain if you're using complex javascript/ajax.
In short, instead of storing the session id in a cookie, you embed it at the end of every link.
so
http://example.com/somepage.php
becomes
http://example.com/somepage.php?SessionId=ABC123
Unfortunately, while PHP can do this for you in some cases, it doesn't help with links you build yourself in javascript - and it only takes clicking a single link without the id to effectively log the user out
See this page for more information
As mentioned by Quentin in the comments, if you're not using a cookie to identify the browser which created the session, it's possible that sharing a link would share the session. This could be mitigated but not prevented by checking IP address/user agent but this would likely fail in large corporate environments with NAT and standard browsers
I’m adding a notification to my website about a new feature that has been implemented. The notification is near the top of the website, in an eye-catching place to get people’s attention. Using jQuery, I wrote a small function that hides the notification when the user chooses to. If the user chooses to hide the notification, I want it to be hidden permanently for the remainder of the visit and on future visits to the website.
What would be the best way to make sure that when they return to the website later on, the notification is hidden? I thought about sending an AJAX request that creates a cookie when the user initially hides it, then checking for the cookie when the page loads, but I’m not sure if that’s the best way to do it. I don’t want to hide it based on IP address because I’m afraid that two users on the same network but different computers might access the website, and one will miss it, but maybe I’m being too paranoid. Any ideas on the best way to do this?
Why not just create/read the cookie with javascript?
I would suggest using javascript to set/read the cookie as well. Since you're already using jQuery I would suggest the jquery.cookie plugin. The only reason for doing an AJAX request to save the user's preference is if your user is logged into the site and you want to store their preference in a database or some other persistent storage so that whenever they are logged in they don't see the message about your new feature.
If the server does not need to be aware of the value of the cookie I would suggest you use localStorage instead.
localStorage exists on the client and does not get sent with the $_COOKIES header to the server.
More can be read about localStorage here
And even more can be read as per why you would want localStorage over cookies for client side data here Local Storage vs Cookies
Pretty basic question here. In PHP, if the user's browser has cookies disabled, you cannot make use of both server cookies ($_SESSION) AND client cookies ($_COOKIE, setcookie) or only the latter are disabled?
Basically you can't make the user log in or do anything that requires a session, right?
Also, in which case would someone want to have cookies disabled?
Thanks!
Yes, it's true. Both sessions and normal cookies are normal cookies. If a user does not accept cookies, he cannot use any of the functionality enabled by them. Which means pretty much the whole internet would break for that user, which is why in this day and age there's virtually nobody who has cookies disabled entirely.
PHP has a built-in mechanism called transparent session ids, which automagically rewrites all links to contain the session id in a query parameter. I would not suggest using it, since session ids in the URL open up a whole new can of worms.
For user friendliness, I'd recommend you test whether the user has cookies enabled or not (set a cookie, redirect to the next page with a flag in the URL that cookies should be set, see if you get any cookies back) and if not, kindly advise the user to enable them.
You can track the user by $_GET.
Imagine that on every-single-page the user visits you pass a ?user_id=XYZ123 then you would have implemented a very similar server-identification. It has obvious disadvantages:
if you copy/paste a URL you'll give away your session_id
because of 1 session high-jack is even less tech savy
Why do users disable cookies?
Users tend to throw first and third party cookies all in the mix but they come from different breeds.
First party cookies are generally ok. When you visit Facebook it's expected that Facebook keeps a cookie to store your interactions with the server.
What it's not expected is that the advertising company that has adds both on Facebook and on eBay gets your cookie back and checks, ah, so this guy was on eBay looking for xyz so now that he's on Facebook I'm gonna show him up abc to make him buy etc etc...
I think you should read the session reference manual http://www.php.net/manual/en/session.idpassing.php
In short, if your server can't find session_id, he can not restore session. But you can use alternate ways to store session values. Or you can generate session_od base on user's client environment parameters.
I do a lot of php and javascript, but I think this is relatively language-agnostic question. Are there any best-practices for when to use each of:
URL variables
SESSION variables
cookies
I understand the inherent limitations of what some of them can't do, but it seems like their use can overlap sometimes, too, and those instances are what I'm really asking about.
EDIT
Just to clarify: I'm pretty familiar with the technicalities of which method is stored where, and which the client/server can access. What I am looking for is something a little higher-level, like "temporary user settings should live in cookies, data state info should live on the server, etc..."
Thanks!
In general:
Use URL (GET) parameters for sending simple request parameters to the server, eg. a search query or the page number in a product listing.
Use session variables, as the name indicates, to store temporary data associated with a specific user session, eg. a logged-in user's ID or a non-persistent shopping cart.
Avoid using cookies when possible. Use them sparingly to store settings that are tied to a particular computer / user profile, eg. a setting such as "remember my user ID on this computer".
Sessions are stored on the server, which means clients do not have access to the information you store about them. Session data, being stored on your server, does not need to be transmitted in full with each page; clients just need to send an ID and the data is loaded from the server.
On the other hand, Cookies are stored on the client. They can be made durable for a long time and would allow you to work more smoothly when you have a cluster of web servers. However unlike Sessions, data stored in Cookies is transmitted in full with each page request. You should use cookie if you need longer logged-in sessions.
URL variables (GET) are open and can be seen by user. They are also useful as it allows the user to bookmark the page and share the link.
PHP embeds the session id directly into URLs when cookies are disabled. Then, the session id becomes a value accessible thru an HTTP GET variable.
Is PHP sessions the same as cookies? I ask this because I'm writing a privacy policy and the site uses PHP sessions, MySQL, JQuery and CSS. If Session are not the same should I change or leave the cookies name?
Here is what I have so far.
Cookies - The Website uses "cookies," a technology that stores a small amount of information on a user's computer to permit the Website to recognize future visits using that computer. Cookies enhance the convenience and use of the Website. For example, the information provided through cookies is used to recognize you as a previous user of the Website (so you do not have to enter your personal information every time), offer personalized content and information for your use and otherwise facilitate your Website experience.
PHP sessions are stored, by default, in a temp directory on the webserver. The session id is stored in a cookie called PHPSESSID. By default, these are not tracking cookies and don't have to be persistent (e.g. they expire whenever you close your browser). So they are safe to use even in websites that have enforced privacy regs.
For instance, I worked for a major branch of the U.S. military and we used _SESSION's all the time, despite the U.S. government forbidding a great many types of cookies.
To make a session cookie non-persistent:
// Make the session cookie last for 24 hours.
ini_set('session.cookie_lifetime', 86400);
Sessions are stored in the server, and after an previusly set ammount of time, it dies, or in other words, its deleted. Sessions do not need permission from the user to create, as a matter of fact, php initializes a session for each new web request that arrives from an ip to the server.
Cookies, on the other hand, are data stored in the browser's data folder, and every user needs to authorize the site to use them, and of course, they are not shared, meaning that IE and Firefox cannot share a cookie.
An example would be to login in this site and next time you point your browser it will remember your credentials, but if you try to open it with IE, it won't know who you are, hence the fact that they don't share data.
Hope it helps
Best of luck!