Given a third-party webpage www.somepage.com handing out specific URLs to subscribed websites in the format of www.somepage.com/site/3ir3jsd - how can I track that a user having an account on www.somepage.com has visited one of the subscribed websites without resorting to cookies / localStorage ?
A standard approach would be to store a cookie for www.somepage.com and add www.somepage.com/site/3ir3jsd via an IFrame. This has several issues as new laws and browser defaults prohibit third-party cookies and local storage to be loaded.
Is there some other mean to achieve this? I see that this is a potential privacy issue and would of course ask for permission to do this and would prefer secure / non-privacy-infringing methods. All major browsers have to be supported which rules out browser extensions too (looking at you Internet Explorer 9-11). Maybe JavaScript? But I don't want the user to have to "login" to my pages service on every subscribed webpage. Storing their session cookie in the first-parties localStorage / cookie is a potential security risk though (which would be needed when using JavaScript + storing their session data).
Another approach I have checked is client certificates but they are poorly supported (read: often unsupported) by mobile browsers and the use-ability of adding them is horribly in most of them too.
I launched two different instances of JBoss AS 7.1 on my machine on two different ports and deployed the same application (with the same root context) to both of them. This configuration gave me, deterministically, the following exception as I was doing tabbed browsing with the same browser (either Chrome or Firefox or Conkeror):
javax.servlet.ServletException: viewId:/whatever.xhtml - View /whatever.xhtml could not be restored.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
When I was browsing with different browsers things were ok.
Upon further investigation on how different browsers store cookies I discovered that the combination (IP / path) has to be unique to avoid such tabbed browsing problems and that the port does not come into play. I.e. cookies are stored per IP and per path but not per port. So doing tabbed browsing with the same browser on two different applications deployed on the same IP and path (but obviously on separate ports) will result in expired views as the browser mixes up the two sessions. I recognize that my setting is unlikely to arise in a production environment but I would like to ask:
is there any standard that defines this cookie organizing behavior?
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
is there any standard that defines this cookie organizing behavior?
Version 0 cookies (Netscape spec cookies) do not support ports in any way.
Version 1 cookies (RFC2965 spec cookies) supports the Port attribute. If this is absent, then version 0 behavior is used.
The average servletcontainer sets the JSESSIONID cookie as a version 0 cookie. You could theoretically override this by providing a custom "Session Manager" in the servletcontainer. Note that MSIE 9 does still not support version 1 cookies.
are there any best practices one must be aware of in order to avoid session mixups when doing tabbed browsing in multiple JSF applications?
The canonical approach in real world projects is to use a different subdomain (on same port!). E.g. beta.example.com, dev.example.com, update.example.com, test.example.com, etc.
does the javax.faces.STATE_SAVING_METHOD have any bearing on this (in my setting it was set to "server") ?
If you set it to client, then the ViewExpiredException will indeed disappear as the view is not stored in the session anymore, but instead in a hidden field of the form. But you might still face other session-related trouble, for sure if you're storing some stuff in the session, such as session scoped managed beans and the logged-in user.
For data security and privacy reasons I want to know why Magento uses two cookies for one frontend session.
All I know is that one of them is being set in Mage_Core_Model_Cookie::set(..) and the other one in Zend_Session::expireSessionCookie(), but still I can't seem to figure out what they are used for.
I just can't think of any reason why one would need a second cookie for the same domain.
I'm going to call this one vestigial code. Varien relies heavily on the Zend Framework as the underpinning for Magento, so many of the classes (Zend_Session for instance) are used as parent classes for Magento implementations.
The Varien-set cookie labeled "frontend" is namespaced for the section of the site you visit (e.g. you will have a separate "admin" cookie if you log in through the backend), whereas the Zend cookie appears to be global.
Also note that I was able to delete the Zend cookie without any apparent deleterious effects (my login session and cart remained accessible, and the cookie was not immediately replaced).
I was able to fix this by reversing the order of the session_start() call and the statement that sets the cookie in Mage_Core_Model_Session_Abstract_Varien::start(..). Those two lines now look like this:
$cookie->set(session_name(), $this->getSessionId());
session_start();
It now only creates one single cookie and it does not seem to have any side-effects.
BTW: The other cookie was not created in Zend_Session as I assumed, but instead both of them came from Mage_Core_Model_Session_Abstract_Varien::start(..).
That is interesting. I just checked on an install of enterprise edition and only "PHPSESSIONID" is set, "frontend" and "admin" are missing even when logged into both. Perhaps this is something still actively being developed.
Suppose I have a web app that I want to embed into any other site using an iframe. The iframe references my site and operates independently of the hosting web page.
Well, the browser considers the iframe to be a third party site, therefore its session cookie is considered a third party cookie. Some methods exist to make the browsers happy (e.g. P3P header), but it's still possible the user would have third party cookies disabled entirely. If so, then session cookies can't persist in an iframe.
What are good methods for persisting a session in an iframe on a third party site?
I have faced a similar problem you have here. There is a workaround (Will not work if your intention is to track user behavior across sites).
i. Place a first party persistent cookie on the domain where your iframe is to be hosted. (This can be done using JavaScript).
ii. Dynamically inject the iframe and pass across the value of the cookie to your site.
iii. If you intent to track user behavior across sites, modify the above code so that you use third party cookies when the browser allows, else switch you use the above approach.
I haven't come across any other way to work around this. If you find a more acceptable solution do let me know.
My intent is to track a session within the iframe, so that clicks and reloads maintain state. It's not necessary to link sessions between the iframe and the hosting site.
The best I could come up with is cookie-less sessions. It's a bit manual, but with this site running PHP, I just need to ensure the querystring always contains "PHPSESSID=x" and it'll automatically attach to that session id.
If the owner of a web site wants to track who their users are as much as possible, what things can they capture (and how). You might want to know about this in order to capture information on a site you create or, as a user, to prevent a site from capturing data on you.
Here is a starting list, but I'm sure I have missed some important ones:
Referrer (what web page had the link you followed to get here). This is a HTTP header.
IP Address of the machine you are browsing from. This is available with the HTTP headers.
User Agent (what browser you are using). This is a HTTP header.
Cookie placed on a previous visit. This is a header, available only if a cookie was placed earlier and was not deleted by the user.
Flash Cookie placed on a previous visit. Some users turn off cookies, but very few know how to turn off Flash cookies. Works like a normal cookie although it depends on Flash.
Web Bugs. Place something small (like a transparent single-pixel GIF) on the page that's served up from a 3rd party. Some third parties (such as DoubleClick) will have their own cookies and can correlate with other visits the user makes (for a fee!).
Those are the common ones I think of, but there have to be LOTS of unusual ones. For instance, this:
Time on the user's clock. Use JavaScript to transmit it.
... which I had never heard of before reading it here.
ADDED LATER (after reading this):
Please try to put just ONE item per answer, then we can use voting up to sort out the better/more-interesting ones. The list below is probably less effective.
Ah well... NEXT time I ask a question like this I'll set it up better.
And here are some of the best answers I got:
James points out that IE transmits the .NET framework version.
AviewAnew points out that one can find what sites you have visited.
Mecki points out that Screen Resolution can be determined.
Mecki also points out that any auto-fill information your browser has cached can be determined, by creating a hidden field, then reading it with JavaScript.
jjrv points out that Flash can list the fonts on the user's machine.
Kent points out that you can find out what websites a person has visited.
Silver Dragon points out you can determine the location of the mouse within the browsing window using Flash and AJAX.
Jim points out that you can tell what language the user has configured in their browser from a HTTP header.
Jim also mentions that you can detect whether people are using Greasemonkey or something similar to modify the page.
Modifications to your original:
can be escaped ( i think its an option in some browsers )
only avoidable with a proxy ( javascript can contravene this however with smart lookaround )
is unreliable, easily forged.
And assuming it was not wiped by browser closure ( session cookie ) and cookie is in the same domain/path
The real nasty ones are
Using javascript to probe your network/lan
Using javascript to access your firewall from behind the firewall and adjust its settings ( no joke )
Using the feature of the "visited link" to determine which of a list of urls have been visited. ( deep history probing ! )
Goodness knows what if the user has Windows/IE/ActiveX
There's a header that can include information about a proxy server the user is using, and that can also include the user's IP address (in which case the other IP is the one of the proxy)
Screen Resolution, Operating System, Color Depth, size of your taskbar (compare max and current resolution), if Java is enabled, Anti-Aliasing Fonts, Plugins Installed all via Javascript
A Java applet can give you a bunch of information as well, but I don't know what.
Sites you've visited
Details of your local network such as active hosts, web servers. Paper Also outlines drive-by printing, drive-by router modification
And this is all assuming the attacker doesn't pull off arbitrary code execution
Javascript can get more information than just time. E.g. screen resolution (+ color depth) being one of them.
See Getting Screen Resolution with JS
Everything JS can capture, can be transmitted using AJAX without the user performing any interaction. Other examples are (not all will work in every browser):
It can look into your browser history, e.g. what URL your browser would go if you hit back or forward.
The language of your browser (Note: usually the HTTP request will also contain a list of preferred languages for the page you request. However this list is user editable in the prefs of many browser, while JS can actually find out what the language translation your browser is using in the interface)
If your browser auto fills form fields (e.g. e-mail, username, etc.), JS can actually already read what your browser entered into the fields before you submitted the form (thus it can even read what your browser pre-filled there, even if you never submit the form at all).
A Java applet could also gather some information and transmit it, though there is not much information you wouldn't already get elsewhere. Since it's easy to get the IP of a visitor, it's possible to find out which online service he's using (looking up the IP at address services like IANA for USA or RIPE for Europe and so on) and there are services that translate IPs to country, so it's possible to find out where the user most likely is currently located.
Some additional info, that might be of interest:
Using the ip address, one can resolve the hostname, net provider / organization the IP belongs to, and rough geographic location.
Using the referer, the list of queries a specified client makes, and a reliable cookie mechanism, one can resolve the path the visitor makes (even clickthroughs to other sides, with AJAX and/or a forwarder page)
Using flash, with a combination of AJAX, the mouse location within the browsing window can be captured
The User Agent might contain information regarding operation system, installed .NET frameworks, and other curiosities
.NET framework versions are transmitted in IE, in the User Agent.
Flash can give you a list of fonts on the user's machine among other things. Javascript can send information when the mouse stops over an ad without clicking it. You can also get the window size, whether the site is open in a frame, if popups or specific plugins have been blocked, looking for Javascript features can tell if the user agent header is correct or faked...
If you're concerned about your personal security (I'm not sure if that's what you're really getting after, so my apologies if this is misguided), you can always use a Tor network. If you use Firefox, you can use Torbutton for one click enabling. It has the benefit (drawback, to some), of disabling Flash because it's otherwise impossible to protect against Flash information leaks.
You can usually determine which language the user speaks through the Accept-Language HTTP header.
You can determine whether certain applications and browser plugins are installed by looking at the Accept HTTP header.
Browser version/patchlevel and .NET framework version through the User-Agent HTTP header.
Your ISP/Employer and geographical location through IP address.
Whether or not you have visited particular URLs through CSS and/or timing load events. If a particular website has user-specific URIs, this could disclose whether you are a certain user on that site or not.
Which fonts are available through measuring ems and/or Flash.
Screen resolution, window size, timezone through JavaScript.
Where you move your mouse and keystrokes through JavaScript. For instance, you can see what people type into text boxes even if they don't hit submit.
Many UserJS/Greasemonkey scripts leak information (e.g. if you filter out certain people, the sites it is configured for may be able to find out who).
Can the browser support JS
Can the browser support flash
Operating system platform
Screen resolution
Supports CSS
Supports tables
I need to dig up the link, but if the user is using IE, with common software titles installed, determining which ones are installed is possible.
As far as I know, it's possible to get clipboard data via javascript. Not sure how possible it is by default these days, but it was all the rage not long ago. I do believe IE still allows it.
People have a habit of leaving very important data in their clipboard, so this is pretty bad.
late to the party here, the website can also scan your ports, to find what software you are running!