Is there such a thing as a unique browser $_SESSION id? - php

I am working on add to favorites add-on (where posts will be added to favorites by signed in users), but then I saw that craigslist lets anyone add favorites without them being signed in. How do they do that? Is there a unique $_SESSION id for a browser? Sorry if it's a silly question.
As an example: http://orlando.craigslist.org/search/jjj (Click on any star to add to favorites. May not be available in IE 11).

They are just using a session, you should be able to check this by looking what cookies they are storing on your computer.

Everything in $_SESSION persist only for the current session. If the users closes the browser and reopen it a new session is generated. So $_SESSION is not the right place for your answer.
There is $_ENV where you can get the clients ip address and general browser data from. In most cases this is enough to identify a single user. If you keep track of these data you can prevent users from giving multiple votes.

Related

Check if a User Has Clicked on a Button

What I would like to do is essentially check whether or not a user has clicked a certain link on a page. The idea behind the functionality is that a user can click "Thanks!" on a post created on the website, but they can only submit one "Thanks!" per post.
I have no problem creating a simple click counter for the "Thanks!" button, and save the count to a database using PDO, but I am not sure how I can assign a click to the user who's session is active.Also, posts are constantly being added to the site, so I would need a system which would scale to more posts automatically.
Any guidance is appreciated, thanks!
Note: I know I have not put any example code, but I believe this is simple enough for a good programmer to grasp quickly.
EDIT
On further thought, the IP can not be used to distinguish users, as this website will be used by many people on the same IP.
Are the users logged in or anonymous? If they are logged in just save their user id in a session variable and upload it with their vote to a table in your database.
I do something similar using an Ajax request to a .php page that inserts a row with the session user ID and the vote.
If they are anonymous you can save their ip but that leads to problems with users who share the same ip address. Another (bad) option is to use cookies but users can obviously just clear their cookies and vote again.

PHP Server options and voting system

I am currently creating a website that allows anonymous users to input data (or comments) into a database and allows other anonymous users to the site to vote up or down the comments presented on the site.
I have already created the functionality to allow a user to create a comment and allow another user to vote on the comment. The problem I'm having though is thinking how I can limit each visitor to the site to only vote on each comment once.
My idea was to create a session ID when the user votes and then when they try and vote again to try and compare if a session ID already exists. This would work but only until the session is destroyed. Does anyone have any other ideas of how this could be achieved?
I am assuming I might be able to use some of the $_SERVER options available
Thanks in advance
Just restrict the voting with IP's or either Cookies, i also created 3 websites in which i had to take the public voting, earlier i did it with IP's but then i changed back to cookies, i also saved IP's along with setting cookies to check if the users are deleting cookies again and again to vote, but i never had such problem, so my opinion in just go with cookies, because not everyone can find that we are doing it with cookies.
It's impossible to enforce a one-vote policy on an anonymous user system. Like said in a comment above:
Trying to control "Anonymous" is nearly impossible. IP's are shared,
sessions are temporary, cookies can be deleted
You can't identify your clients at 100%, if a user would want, he will be able to bypass whatever means you attempt to use and vote more than once.
Your only reliable option is to enforce registration and only allow registered users to vote.
If you still insist, you can try to make it difficult for users to bypass your enforcing system. Use a combination of the user's IP address, and a lasting cookie, and cross-validate against both to ensure the user doesn't vote twice. But again, do note that a user can easily delete cookies and on most cases, change his IP address.
When you are inserting comments for specific article, store the member (who is commenting) id or name or any thing unique. Put the verification code before inserting the comments ....
Select * from articles where member_commented_id = [current_member_id_from_querystring) and article_id = member_commented_on_article_id
//a check point
if result is > 0 .. its mean member already has commented on this article
//otherwise
add comments on article and insert member id as well for checking
// if you are using seperate table for comments then you have to make additional field in table like
comment_id, comment, com_date, member_id_who_commented, article_id_on_which_commented
Making IP or Cookies check point is not reliable because IPs are changed by the ISP (if set to dynamic IP) and Cookies can be cleared by visitor
Hope this helps you

How can I make remember voting with cookies easier than this?

It is the most easiest to describe my problem with a working example: even if you are not logged in, YouTube remembers what you have watched, and next time gives you suggestions based on previous watched movies.
My site is similar in a way: the users can vote on articles without logging in, and the site remembers votes with cookies. I have figured out a working method, but there has to be an easier way - also now the DB usage is anything but optimized.
For every visitor there is a check if he has the cookies. If yes I query his votes. If not I create a dummy user, and send him out the cookies. Now I store this users "last_visit" timestamp. After this everything is the same for both users. My problem is that my DB is filling up with dummy users, so I made my cookies expire in 3 months and my site regularly check which users didn't visit my site in the last 3 months, and deletes them from the DB.
I know I overcomplicated this, but my vote system is using AJAX, and I couldn't find a method to send out a cookie (and create the dummy user) only if a vote happens and not every time a simple visitor browses my site - without vote.
Also a note: I insist on using cookies - I know it would be easier to store IP-s when a vote happens, but there are schools, businesses using the same IP, and I like to allow their users to use my site.
What did I miss here? How can this be optimized?
if they do not hold a permanent account, why store anything related to them in the database at all? just record their prior votes in the cookie. you would also store averall votes in the db, but anonymously, and not relate these to "users" at all.

same logged in user assigned different session ids (in different browsers)

I've implemented a mysql-based session interface in php.
I just found out that if I log in to my account using browser A (e.g. Chrome), and then I log in to the same account in another browser B (e.g. IE), each browser is assigned 2 separate session ids. How can I make it such that when I log in again using browser B, I retain the active session of the previous browser A?
The issue at hand is that I'm storing certain information in the session and the data not being synchronised between the same users in different browsers and is wrecking havoc. :S
Is there a way to achieve this?
Thanks!
If you're storing the session in the database, add a mechanism whereby the userId is stored as part of your database's session record, creating what I like to call a "semantic session". When the user logs in, check to see if another session already exists; if so, use session_id() to fixate the new session to the old session's ID, which will join them (and should change your new session's ID for all subsequent requests). Be sure to only perform this action during the login step, or you might end up with freaky race conditions of two sessions trying to be each other and "swapping".
Don't store the data in session, store it in the database.
Sessions are normally identified by cookies, which are only visible in one browser. You could probably use Flash to share the session ID between browsers, but I cannot think of a use case. The point of the session is to store data which is bound to a single browsing session, and not to the user in general. You should use a database or some other form of server-side storage for generic user data.

Storing real time data

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.

Categories