I have a cookie which is sent from the client which is used as part of my MVC web service, however now that I have integrated a hub into this application the hub doesnt get sent the cookie, whereas the mvc app does.
Now after reading other similar questions (not that there are many) the cookies domain seems to be to blame, or the path is not set.
Currently my system has 2 web apps, the ui and service. In my dev environment it is like so:
Service
http://localhost:23456/<some route>
UI
http://localhost:34567/<some route>
So in the above example, the ui will send a query to the service, getting an authorisation cookie on the response, which is used elsewhere.
In this example the cookie domain from the service is localhost, as from what I have read and seen on other questions there is no need for a port, it will automatically just allow all ports.
Are HTTP cookies port specific?
SignalR connection request does not send cookies
So it would appear to me that the cookie above has correct domain, and the path is set to /, so it should work. However it doesn't send them in the request from javascript.
My request is a CORS request so I am not sure if there are any quirks around that but all normal jquery ajax calls make it to the server fine with the cookies, any ideas?
OH also my cookies are httponly as well, not sure if this makes a difference...
== Edit ==
Have tried to rule out some stuff, have turned off httponly and it still refuses to send the cookies to the server, I have also noticed a few outstanding cookie issues which mention adding the following code in somewhere to make ajax behave a certain way:
$.ajax({
xhrFields: {withCredentials: true}
})
Tried using that and still no luck, so I am out of ideas.
I raised an issue as there is an underlying issue with < version 2 beta of SignalR relating to CORS and cookies.
https://github.com/SignalR/SignalR/issues/2318
However you can manually fix this issue by appending:
xhrFields: {withCredentials: true}
to all ajax requests within the jquery.signalr-*.js, this will then send cookies over CORS, although I do not know if this has any adverse effects on older browsers or IE.
Related
I have two Spring Web applications that work together. I'm running the first application from the IDE on localhost, while the second one is running in docker on app.127.0.0.1.nip.io.
The two applications interact indirectly through the users browser by redirecting and POSTing between the two apps. This is slightly similar to how an SP and an IdP work together in SAML2.
In my case, the first application on localhost is sending a 302 to the second application. After doing some work, the second application sends an HTML page with a form an JS code to autosubmit it, back to my first application on localhost. The HTML looks similar to this:
<form method=POST action="http://localhost:8080/some/path">
...
</form>
My first application is using Spring Session with a session cookie, and this works just fine. However, when the second application makes the browser POST the form, the browser does not send the session cookie with the POST request.
When both applications are running in docker under .127.0.0.1.nip.io, the cookie is sent.
I've tried to find any hint if this behaviour is expected, and what headers or other bits the applications could use to influence this.
At this point, this is mostly an annoyance while debugging, but I'm concerned that once the two applications will run on different FQDNs and/or different domains, the browsers will also block the cookie being sent.
I've tested this with current versions of Chrome and Firefox.
The problem is the new(ish) SameSite cookie policy that covers exactly this case: another application is POSTing to a host via HTTP. The default now is SameSite: lax, which does not allow sending the first-party cookie values on this request.
The solution is to allow the session cookie to be sent by specifying SameSite: none. Be aware however that this might create security vulnerabilities. For my application, this is not an issue, so I can allow the cookie to always be sent, and especially when I run my application in the debugger.
For the production deployment, I will be able to tighten this, since both applications will run under the same domain (a.example.com and b.example.com), and both will use TLS, so I can set the session cookie to SameSite: lax.
Here's a decent explanation: https://web.dev/samesite-cookies-explained/
I've been using Postman in my app development for some time and never had any issues. I typically use it with Google Chrome while I debug my ASP.NET API code.
About a month or so ago, I started having problems where Postman doesn't seem to send the cookie my site issued.
Through Fiddler, I inspect the call I'm making to my API and see that Postman is NOT sending the cookie issued by my API app. It's sending other cookies but not the one it is supposed to send -- see below:
Under "Cookies", I do see the cookie I issue i.e. .AspNetCore.mysite_cookie -- see below:
Any idea why this might be happening?
P.S. I think this issue started after I made some changes to my code to name my cookie. My API app uses social authentication and I decided to name both cookies i.e. the one I receive from Facebook/Google/LinkedIn once the user is authenticated and the one I issue to authenticated users. I call the cookie I get from social sites social_auth_cookie and the one I issue is named mysite_cookie. I think this has something to do with this issue I'm having.
The cookie in question cannot legally be sent over an HTTP connection because its secure attribute is set.
For some reason, mysite_cookie has its secure attribute set differently from social_auth_cookie, either because you are setting it in code...
var cookie = new HttpCookie("mysite_cookie", cookieValue);
cookie.Secure = true;
...or because the service is configured to automatically set it, e.g. with something like this in web.config:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
The flag could also potentially set by a network device (e.g. an SSL offloading appliance) in a production environment. But that's not very likely in your dev environment.
I suggest you try to same code base but over an https connection. If you are working on code that affects authentication mechanisms, you really really ought to set up your development environment with SSL anyway, or else you are going to miss a lot of bugs, and you won't be able to perform any meaningful pen testing or app scanning for potential threats.
You don't need to worry about cookies if you have them on your browser.
You can use your browser cookies by installing Postman Interceptor extension (left side of "In Sync" button).
I have been running into this issue recently with ASP.NET core 2.0. ASP.NET Core 1.1 however seems to be working just fine and the cookies are getting set in Postman
From what you have describe it seems like Postman is not picking up the cookie you want, because it doesn't recognize the name of the cookie or it is still pointing to use the old cookie.
Things you can try:
Undo all the name change and see if it works( just to get to the root of issue)
Rename one cookie and see if it still works, then proceed with other.
I hope by debugging in this way it will take you to the root cause of the issue.
I need some help in resolving a strange behavior I came across while using Thinktectures Embedded STS locally in my ASP.net MVC application. I don’t see this issue on the server using ADFS.
The issue is
After I sign in into the application, most of the HTTP calls from then on are getting called twice.
The first HTTP request goes without the FedAuth cookie to which the server responds with a status code of 302 (redirect) and another request to the same URL is made but this time with the Fedauth cookie. I'm trying to understand what is causing the browser to send the first request without the FedAuth cookie and also why the server redirects to the same URL?
I also need help in understanding how the EmbeddedSTS URL gets resolved. I went through the code on Github but it is not very clear to me how the EmbeddedSTS url is resolved.
Any help is appreciated.
I was able to figure out the issue on my own.
This issue is related to cookie paths being case sensitive. My virtual directory in localhost was configured as ATSWeb but while making AJAX calls I am constructing the full URL with a different case for the virtual directory (atsweb).
Since the ADFS cookie was set with the path /ATSWeb, while doing the AJAX call the browser is not sending the Fedauth cookie to the server. This is leading to all sorts of issues.
You can read more about cookie paths at the links below.
http://www.allbacktomine.com/blog/2009/02/04/BrowserCookiesThePathIsCaseSensitive.aspx
Why are cookie paths case sensitive?
Is there any case where the browser is sending an HTTP request to a server but does not attach cookies associated with that domain to the request? If so, what are the cases?
Cookies are set by the server first, or are set by a javascript that is executed in a page from that domain. So every cookie you get, it a cookie you have set earlier.
Normal cookies are sent to the server with each request, Ajax as well as regular page loads and posted data. There are some new features like offline storage that is implemented by more and more browsers, but those features are not cookies.
A cookie can have a domain and path associated with it, thus limiting which resources the cookies are sent to.
document.cookie = 'name=value; expires=' + date.toGMTString() + '; path=/myFolder; domain=myDomain';
Yes.
Chrome (as of version 25) does not include cookies in favicon requests. Also, it is apparently standard for other browsers to not share cookies between the favicon requests and other requests.
I would like to load cookies everytime and everywhere in my website because when my RoR application receives and accepts an "external" HTTP request (ex: REST API), cookies are not loaded (see RFC2109). So their values are inaccessible.
Cookies are accessible only when the HTTP request is made "internally" in my application.
new_cookies = {"Cookie" => "mycookie=1234;myothercookie=4567"}
Net::HTTP.get( URI.parse( http: //app1.website.com/users ), new_cookies)
All browsers will automatically send any cookies you set from your domain, you can check them simply by calling request.cookies from any controller method. It doesn't matter if the request was initiated from within your application (such as a 302 redirect) or not.
I just tried this with Firecookie:
Created a cookie "mycoolcookie" for the domain ".stackoverflow.com"
Went to stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to meta.stackoverflow.com, firebug showed that the cookie was sent in the request header.
Went to chat.stackoverflow.com, firebug showed that the cookie was sent in the request header.
A cookie is sent automatically by the browser, the server can never request for a cookie to be sent to it.
REST APIs are generally stateless, therefore you should avoid the use of server-side sessions or client-side cookies. If you want to indicate that a user only grabs resources belonging to them, use the Rails nested resources approach, that results in a call like:
http://abc.com/user/user001/books
For all books that belong to user001.
If you are looking to implement security, first you have to use HTTPS instead of HTTP. For the actual implementation you can use Basic Authentication and set the username/password in the request header or you can use something like OAuth which sets up a token for the user that they pass in with each request.