We have an implementation understanding with a merchant to create our domain cookies when user is on his site. Now in FF assuming that third party cookies acceptance is set we are able to create the cookies and flow works fine. But the issue is that after the cookie is created and third party cookie is disabled later - the request to load an image from merchant site page to ours site - we do not receive the cookie details.
Is it an expected behavior or we need some special mechanism to get the cookie?
Please help.
You may already know this but cookies are domain based. You can only access cookies on requests for the same domain.
If your image is displayed on sample.com and your the url of the image is sample.com/img.jpg then when the request is made for the image the cookies will be sent along with the request.
On the other hand if the image is displayed on sample.com and the image url is yoursite.com/img.jpg then you won't receive the cookies for sample.com.
Also, dev.sample.com and sample.com are different domain names.
Hopefully this helps clarify why you can't receive cookies. This behavior is mainly security related to prevent websites from sniffing cookies from other sites.
Related
I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
I have recently been reading about session ID's and how websites track users.
I was wondering how session ID's are safe inside cookies. Couldn't a website read another website's cookies and get your session ID?
Cookies are stored on the client's browser with cookie name, value and the expiry. But multiple websites may have cookie with same name so cookies are grouped with respect to domains. See the Firefox's cookies screenshot bellow.
Suppose sites A and B have cookies with name ABC. Browser will provide the cookie data for site A from site A only.
In an application I implemented an javascript chat with long polling. Since there is just one Ajax Request per domain allowed I wanted to move the poll request to a subdomain.
So I have two domains:
dev.site.com
poll.dev.site.com
In my config.yml I entered the following:
framework:
session:
domain: .dev.site.com
cookie_domain: .dev.site.com
But Symfony does not keep me logged in if I try to poll on the sub-domain via Ajax.
Any idea on how to keep the session on the sub-domains?
I'm using the FOSUserBundle
First, the two applications need to share the fos_user table so they can reload the user when. As you have "one app and the two domains pointing to the same app." this should already be correct.
Next is to set the session cookie to be shared between the domain and the subdomain. The config in your question is correct. However for FOSUserBundle to be able to reload the user when you change from dev.site.com to poll.dev.site.com you need to share the session storage between the two domain.
The easiest way I can suggest is to store the session in a database. This is achieved by using the PdoSessionStorage available in Symfony. The official documentation covers how to setup the session storage to do that.
If all above is done correct you should not able to login to an secure area on dev.site.com, and then change the URL to an other secure area on poll.dev.site.com without any need provide login credentials again. Notice that the user credentials are only loaded in an secure area.
When it works to open poll.dev.site.com directly in the browser with any need to enter the credentials again. You need to do some additional work to get the Ajax request to work.
According to these two questions: Setting a cookie on a subdomain from an ajax request, multi-sub-domain cookies and ajax problems the problem is likely the http://en.wikipedia.org/wiki/Same_origin_policy.
The first suggests setting the following header fields on dev.site.com:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://poll.dev.site.com
And then passing withCredentials on the ajax request.
$.ajax({
url: 'http://poll.dev.site.com/some/ajax/endpoint.json',
xhrFields: {
withCredentials: true
}
});
I've tested it using a dummy file that would just set the cookie and try and ajax request. I got it to worked if I had withCredentials on the ajax request, but I could not see any difference when I tried with/without the Access-Control-Allow-* headers.
The other answer suggested using document.domain but I dodn't test that.
I used using Opera's Dragonfly to inspect the network trafic if the Cookie header was sent to the server when I tested. You can use Firebug, Chrome or probably IE too.
I have a standard HTML login page, which I would much rather use than the standard HTTP authentication pop-up provided by browsers. Today, I am using session cookies to keep track of the session after logging in, but I'd like to be stateless and pass the HTTP authentication every time. The web services I am hitting already support this, so this is a browser-only issue.
Adding authentication credentials is trivial in jQuery, but I don't know how to keep them around. If you go from the login page (a jsp) to the Home page (another jsp) you clearly don't keep the username and password fields from the login page. I know some browsers will store your HTTP authentication credentials if you enter them from the pop-up, but I don't know if they get stored when using an XHRRequest. If they do, is there much consistency among browsers?
Also, the user needs to be able to "sign out" of the application, too. If the browser stores the authentication credentials, is there a way to clear them using JavaScript.
I feel like I can't be the first person to try to solve this. Is there some jQuery plugin or something that already handles this? Or is it simply not possible to do what I'm trying to do?
You have 2 options:
1) Client-side storage of credentials -- not a good idea. For obvious reasons you don't want to store the username/password on the client. If you had a hashed version of the password, it might not be so bad, but still not recommended. In any case, if you're going to store on the client side, you either have to use a cookie, or HTML5 local storage (which is not widely supported, yet)
2) Server-side storage of credentials -- typically done with sessions. Then the resultant Session ID can be passed back to the client and persisted in either a cookie or in the URL of each subsequent AJAX call (?SESSID=xyz for example)
The server-side approach would be the most secure, reliable, and easiest to implement
Okay, I'll take a stab at helping ...
Firstly, understand how HTTP authentication works. There are two versions - Basic and Digest. Basic transmits in plaintext, digest is encrypted. With these types of authentication, the username/password are passed in the HTTP header with every single request. The browser captures these at login and they are stored in an inaccessible browser session cookie which is deleted when the browser session is closed. So, in answer to one of your questions, you can't access these from javascript.
You could create your own session cookie variables for username and password. The jQuery functions for this are really simple. See jquery-cookie module as one example of how to set session cookies. These could be retrieved from the session cookie and sent with each ajax request and validated in the server. However, this is not a particulary good way to do authentication since sniffing the network will allow anybody to easily grab your auth details. But, it would work.
Using session cookie based authentication where the session ID is sent sent with each request is the best way to do this. At the server side, you need to have a function called for every HTTP request. This function should do the following:
check to see if the session has been authenticated
if no:
redirect to login screen
if yes:
do authorization and allow the user access to the page
Most web frameworks support session cookie authentication and the management of session ids at the server. This is definately the way to go.
This is interesting one.
Manage user sessions on server by use of cookies. Create a session when user first accesses the login page and pass the session id/key as value to one of the cookie via response. When the user is authenticated put user "key" info in cookie and "values" in application context at server. Once user is logged, any subsequent request will be authenticated based on session cookie value at server. Authorization will be done based on user "key" passed as cookie value.
On logout clear the session based cookies from server and refresh the site to default page.
Cookies are bizarre with different browsers - just a note ;)
Hope this helps.
Update
The answer below was posted in 2012 and the links are mostly dead. However, since then, a more elegant standards-based approach to the same solution appeared using JSON Web Tokens. Here is a good blog post explaining how to use them.
Most answers miss the point, which is to avoid having any server-side session. I don't want any application state in the server. I'll award the bounty to answer that came closest, but the real credit goes to the rest-discuss group and Jon Moore for the correct answer and to Mike Amundsen for helping me to actually understand it.
The best answer I've gotten is to use a cookie, but not the typical automatic session id cookie given to you by most application servers. The cookie (which will automatically be sent with each subsequent request) is a user identifier and time signed by the server. You can include an expiration time with the cookie so it simulates the typical 30 minute session on a server (which means you have to push it forward with subsequent requests) as well as keeps the same cookie from being valid forever.
The XHR/AJAX part is a red herring. This will work whether you are doing XHR requests or an old-fashioned page-by-page web application. The main points are:
The cookie is automatically sent on subsequent requests so there's no
special scripting required - it's just how browsers work already.
The server does not need to store any session for the user, so the user
can hit any server in a cluster and not have to re-authenticate.
Slightly interesting in that you consider pushing some of the authent to the client. If you want a conventional solution, KOGI's server-side suggestion is the way to go.
But you also seem to be asking questions about memory leaks involving your user supplied secrets. Good questions. But to take a general stab at answering that I'd say it would have to be browser specific. It's browser internals, javascript engine internals -dependent where a client side application (i.e., the browser, or js in the browser) is storing the values the user inputs.
Most likely those values are not replicated needlessly throughout memory, but there's no way to guarantee that. Apart from responsible javascript coding practices, there's nothing you can do to guarantee the limit of locations of user inputs.
Slight digression
The basic point is if you store it on the client it is not really secure -- unless, the serve stores encrypted information on the client with a key that only the server (or the user via their correct credentials), has. So you could conceivably code a JS application to do some authent on the client -- much the same as how bank card (used to?) do POS authent by checking the PIN to the PIN on the card, and not back at the DB. It's based on the (somewhat flimsy) assumption the user has no direct read/write access of the "dark area" cookie/local storage on client / mag strip on bank card. So I would only advise this as disqualifier for false authents and not as a sole qualifier for the credentials.
Main point
If you do want to be stateless, just store user credentials in localstorage, or as a cookie but encrypt them with a server key. When you need them send an XHR with the encrypted / use stored credentials to the server over HTTPS, let your server decrypt them and send them to the callback. Then pass those cleartext of HTTPS to do your authent.
If I have a site (e.g. foo.com) and on the home page of foo.com, there is an image request where the src=bar.com..., will the cookies on the bar.com domain be sent to the bar.com servers?
Yes. HTTP doesn't distinguish between one kind of resource or another (image vs html).
The cookie will typically be included in any type of request, but the scenario you describe is what's known as a third-party cookie (that is, the cookie is set on a domain that is different than the domain of the loaded page) and most browsers offer a privacy setting to block third-party cookies.
A third-party cookie allows the owners of bar.com to place an image (say a banner ad) on foo.com and track the users of foo.com even though those users have never visited bar.com. This is a privacy concern and many users elect to block such cookies.
This question is old, but was the first result on Google for me, so I think it's worth clarifying how this works nowadays (2021).
When bar.com sets the cookie, they can specify a SameSite attribute.
If the cookie is set with SameSite=Lax (or the SameSite attribute is not specified), then the cookie will not be sent for requests for images/iframes/etc hosted on bar.com, but will be sent if the user clicks a link on your foo.com homepage that takes them to bar.com
If the cookie is set with SameSite=Strict, the cookie will not be included in requests to bar.com that originate from another webiste, including if the user clicks a bar.com link on foo.com.
If the cookie is set with SameSite=None, the cookie will be sent to bar.com, including requests for images.
If third-party-cookies are not blocked by the user then most modern browsers will set or send cookies of the third party domain when a request is made to the third party web site. IE 6 has a different kind of blocking mechanism called leashing. wiki: A leashed cookie is a third-party cookie that is sent by the browser only when accessing a third-party document via the same first-party.
Yes cookies are sent on all requests.
This includes "img" and "script" as well as XMLHttpRquest calls from javascript and can be a security issue on script tags as scripts loaded by one website can load scripts from another site and will send their authentication cookies too. This can be exploited to steal data.
Yes, aspx/js/css/image requestion need the cookie verification.