Is it at all possible to retrieve user information that can be used as a unique identifier between domains?
As a quick example of what I am trying to do (not exactly this but the theory is the same) say you had a main website at UK-news.com. You also had three other sites - England-news.com, Scotland-news.com and Wales-news.com, all hosted on the same server.
All 4 sites will share the same database and each would just pull the relevant info out of it. If a user becomes a member of one of the sites, they will also be given the option to become a member of any or all of the others. If a user signs-in to one of the sites he is a member of, and then goes to another how can I get that site to recognise him from the one he signed-in on so he is automatically logged in?
My theory was to store some user information (IP, USER_AGENT, browser, screen resolution, computer name, OS) in the database via PhP and then check against all of those as the user moves between sites. however, even checking against all of these, I am sure it will be possible for two different people to have exactly the same details.
Are there any truly unique identifiers that will guarantee that a person is recognised between domains?
Thanks
Steve
I dont know what is the configuration of your server, but. If one site is under something.domain.com, and another something2.domain.com, and the domains England-news.com and Scotland-news.com are only links to those sites, you can use url overwrite, and cookies sharing over subdomains option in php. But I think that this is not the case. So...
There is no 100% sure user recognition. And this is great, imagine what will happen if there would be. You can NEVER trust user data, and headers data, while sometime you can not even trust $_SERVER array. So there is no option to recognize the same user over few domains.
1) The only answer that is useful is to suggest you to share the user mysql table, and make all the logins and passwords same for each site. IN that case someone can login into another site using the same data.
2) You can try to rely on second hand services like google acount or facebook acount to verify users on your site. But you must remember that there are people without gmail and facebook, and availability of such a site will be reduced.
3) Use a serrvice like forever cookie, or something like that, but this is also not 100% sure. It is using html5 storage, flash objects, and everything to verify if this is the same user. But as far as I know, everything can be ommited, if you are patient enough.
Best regards!
Related
At the moment, I'm working on a website that could use some extra user usability, so I want to launch a couple of modal windows to aid users on their first time visiting of a couple pages.
I want to check if it is a users time time viewing a specific page. I've read about how you can run into problems when using cookies to do this. They can be deleted, the user can use a different PC or device, etc.
Also, I want to check for multiple pages if it's their first time viewing, not only directly after login.
I'm guessing a good idea for this would be to make a separate table with the pages in it that I need and setting a boolean for it if it is viewed or not.
Would this be the best way going about doing this?
There isn't a highly reliable way of doing that:
You can use cookies, but as you said, they are not reliable, a user can change PC, delete cookies, change browser, etc.
You can try using an IP address, but that's also not reliable. If a user switches address (which can today happen as you walk down the street with your mobile phone) he'll see the page over and over again. Moreover, if some other user happens to stumble upon the IP address the first user used, he won't see your tour/tutorial.
What I can suggest you is that you use cookies to detect if the user is new, but don't automatically throw the help modules on him, but prompt him using an non-obstructive toolbar at the top or bottom (never a popup window or lightbox).
That way, you get most of the users (because many people use the same browser and computer and rarely delete all their cookies), and even if a user has deleted his cookies/he still won't be disturbed that much.
There is no reliable approach if user is not registered and logged in with her/his username & password.
As mentioned before, there is no reliable way of detecting users ( and detecting if the user visits the site the first time), I also recomend Madara Uchiha's aproach, also you colud use html5 local storage in addition to cookies, both are not 100% reliable
u can however try user recognition without relying on cookies or html5 storage, but this is extremly complicated, u dont want to do this.
Just to satisfy your curiosity about how to do this, check this epic answer on a related question:
User recognition without cookies or local storage
I think, as I believe, there is no way with no solution. I think, a possible way consists of some parameters which first to be said and and finally by considering those, we can be able to talk about possibilities and impossibilities.
My parameters are in the below;
talk about features of a webpage as "User Detection" and detail them
think about reactions (I mean being fast to click on any elements of a page or not) on a webpage
inspect elements
URL injection
other reactions like click on some parts as spots placed on the page
stay on that page up to a time defined for being and checking authorizing
and so some solutions like the ones above.
I have a big security problem with my program, and I need to make parts of my URL's hidden. I have searched on the net for a solution, with no luck. In my program I have admin and user accounts - the program is simply a database for workers dosie. Admins can see all dosies but the other users can only see dosies that are in their work group. So my problem is, when a user comes to see the dosie, the URL to access the information looks like this: "viewdosje.php?album=108. The problem being that the user can simply change album id and he can see other dosies, which is not good. For example:
"viewdosje.php?album=109"
By changing the number in the URL he can see other dosies. It would be great to hide that part of URL, or am I wrong? Please help me with an idea of some kind. I don't know where to start.
You should not hide the url, but validate the access to the resource in the application instead. When you receive the ID, before displaying content, perform a DB query to see if the current logged in user has access to that resource or not.
Relying on "hiding" URLs is a terrible solution - anyone who can get access to the URL can get access to your private data. URLs can be accessed in all sorts of ways - sniffing web traffic (e.g. at insecure WIFI points), through JavaScript, through guessing, through getting access to browser history, and through all kinds of even scarier routes like trojans, keyboard loggers etc.
If the data in these employee records is sensitive/private, in most countries you are legally obliged to protect it adequately; even if there's no legal requirement, your company probably wants to avoid putting everyone's salary into the public domain.
The correct solution is to design a login mechanism, and assign user rights; when a user tries to access a page to which they don't have access, you send them an appropriate error message. There are numerous solutions for this in PHP - PEAR has a good implementation.
I've no real experience with PHP so I can't help there, but if I was tackling this problem with JSP, or Rails I might do the following:
Perhaps store user identifiable information in a cookie, once authenticated, compare this information to the user database ? Prevent the page being served to unauthorised users if they manually edit the url.
I'm currently working on my Referral System, but I have a problem with protecting it of frauds.
Okay, here's how it works for now:
user registers and activate it's account
user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.
But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.
How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?
Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)
The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.
How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.
Who do you perceive to be the threat?
Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.
Cheers
How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...
Is it possible to get remote username when I get a referral link without involving any server side code from the referral link?
Do you mean like if I clicked a link to your site on Stack Overflow, you would want to be able to see that my username is "Agent Conundrum"? No, you can't do that without the help of the referring site. The only information you should be able to get is the (permanently misspelled) HTTP_REFERER in the $_SERVER superglobal array, which tells you the page the user came from. Even then, there are ways to block or change this so you shouldn't count on it being set (especially since it wouldn't be set if the user navigated directly to your page via the address bar).
Frankly, I wouldn't want to use a site that leaked personal information (and for some sites, even the username qualifies as personal information), and I wouldn't want to use a site that tries to harvest such leaked information without my knowledge.
Generally, any site where you have a legitimate reason to broadcast this information would have some sort of API built in, like FacebookConnect. Even then, it should be strictly opt-in for the user.
As a general thing: no. The HTTP protocol does not involve the transmission of a remote user name.
Hey, it could help to answer if you would be a little more specific on which kind of service are you trying to fetch the data from.
Large/Public services tend to have somekind of an accessible API that you can fork on your referrer, but other than that its mostly that you need to regexp the site and know the structure of the HTML pretty much.
The company I work for has four domains and I'm trying to set up the cookies, so one cookie can be generated and tracked across all the domains. From reading various posts on here I thought it was possible.
I've set up a sub domain on one site, to serve a cookie and 1*1 pixel image to all four sites.
But I can't get this working on the other sites.
If anyone can clarify that:
Its possible?
If I'm missing something obvious or a link to a good example?
I'm trying to do this server side with PHP.
Thanks
Are you having issues due to Internet Explorer and their Privacy stuff?
Session variables are lost if you use FRAMESET in Internet Explorer 6
Back in my former internet days, when IE6 first came out, we had to implement this because it broke some of our tracking. Its amazing that all you have to do is fake it, and everything works fine.
Your on the right track, we had a domain that hosted the tracking cgi that served the 1x1 transparent pixel and tracked what page a user was visiting. We then had a custom parser that would combine that data with Apache logs and dynamically created a graph of users traffic patterns through our website. This was using dot from the Graphviz package.
This kind of thing is pretty easy if you are just trying to do stats, but if you're actually trying to persist user data across domains you'll have to do something more complicated.
The best way to set a cross-domain cookie is to make sure all your sites are subdomains of one master domain, say initech.com. So one of your site, site1.initech.com, sets the cookie with a domain of ".initech.com" and it works fine.
It could be a problem if your sites are on totally different domains though.
Rather than try to set one cookie that each site can access, what you'll have to do is make sure that each site has its own exact duplicate of the original cookie. So, have your site, site1.com, set the cookie for itself and output three 1x1 gifs, or AJAX calls or whatever, to site2.com, site3.com and site4.com setting the same cookie to the same value.
This will be difficult to do securely and reliably ;)
To make sure somebody can't set arbitrary cookies on your domain, you'll habe to pass through a hash of the cookie value on the image tag. If the cookie to be set is "mycookieval", also pass through md5("mycookieval"."somesecretstring".$_SERVER['REMOTE_ADDR']). This is potentially bad because it might allow an attacker to set the same cookie to the same IP address, or possibly to brute-force the hash generation.
You could compensate for this by inserting a record into a backend database whenever you set the cookie, and having the other three sites check against it for validity.
This question's pretty cold, but in case anyone else stumbling on it, or the OP still has need, I've created an NPM module, which allows you to share locally-stored data across domains. It looks like this would exactly address the OP's need here, and it doesn't require all sites share a base domain.
https://www.npmjs.com/package/cookie-toss
By using an iframe hosted on Domain A, you can store all of your user data on Domain A, and reference that data by posting requests to the Domain A iframe.
Thus, Domains B, C, etc. can inject the iframe and post requests to it to store and access the desired data. Domain A becomes the hub for all shared data.
With a domain whitelist inside of Domain A, you can ensure only your dependent sites can access the data on Domain A.
The trick is to have the code inside of the iframe on Domain A which is able to recognize which data is being requested. The README in the above NPM module goes more in depth into the procedure.
Hope this helps!