Per cookie specification this is not allowed (same principle as Same Origin Policy for ajax calls). As far as SOP is concerned, it does not apply, when you are running your javascript from file:/// (for example inside of a UIWebView). This is well documented and working in my example too. What about cookies though?
I have an app that makes a request to a server via javascript running, for all intends and purposes, locally (file:///). The authentication request sets a cookie with name let's say 'alpha', path: '/' and domain 'serverdomain.com'. During logout I need to clear the aforementioned cookie but I get the feeling that my attempts fail because I don't have access to it because it is considered to be from a different domain. Does that sound familiar? Or am I way off here? Is there a way to accomplish such a feat?
EXAMPLE
I am running my javascript on Chrome (using file:/// as the URI). I initiate a login and soon enough I can see the following cookie in the cookie manager plugin (this is not the actual cookie but it looks the same except for the name which we can say it is 'alpha'). The cookie is not marked http only but it has the 'session' and 'secure' checkboxes checked (unlike the screenshot below).
Now keep in mind that if I use the 'inspect element' feature of Chrome and go to 'Cookies', I get a 'There are no cookies for this site'.
During logoff I need to delete that cookie. So I do this in javascript:
document.cookie="alpha=; expires=Thu, 10 May 2000 15:07:07 GMT"
The cookie does not go away. The only way I can make it go away is by deleting it from the cookie manager. Should I be able to delete this cookie (while running from file:///)? If so how?
If the cookie was created on a different domain, this cookie won't be sent by the client to the server on the second domain, so you cannot remove it. You can set a cookie with the same name on this domain but that won't be the same cookie as the one that exists on the first domain.
Related
I am creating a project for school, and I need to create a backend in spring boot and a frontend in vanilla JS +HTML+ CSS. Since both are on localhost but on different Origins namely on port 8080/5500 respectively ,I am having some issues with CORS in that my cookies are not saved in the browser so no session is created between backend and frontend. This leads to the problem that after login in I will not be able to access securised endpoints because it will require me to log in again since no session is established.
What solution do I have for making this work / saving the cookies?
Further I will give several details and images about the issue that I have.
The backend uses MySQL, spring boot and RestControllers. It basically is a simple CRUD that I also added spring security to. Now this is how my Spring Config looks like
and this is how my CORS config looks like
and this is how my fetch request looks like in the frontend.
Also the request to /save
The flow is as follows : I make a request to /login, than I should be able to use the /save endpoint. This works flawlessly on postman since accessing /save works only after /login was successfully otherwise I get unauthorized, but it does not work in the browser because the cookie that is send with the first response is not saved as below. In the following image the response provides the JSESSION cookie after successfully authentication.
But then when I check cookies section, the cookie is not there.
And when I make a request to the /save endpoint I get the following issue
I also tried the answer over here How to set cookie domain and path with Spring boot but cookies are still not saved.
The browser refuses to allow a URL whose host is [::1] to set a cookie with a Domain attribute of 127.0.0.1. Why? Simply because, even though [::1] is the IPv6 equivalent of 127.0.0.1, the latter doesn't domain-match the former.
Anyway, why would you want to set a cookie with an IP address for the Domain attribute? You seem to be misunderstanding the purpose of that attribute; read what the MDN Web Docs page entitled Using HTTP Cookies has to say about it:
The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.
In your case, the host of the URL that sets the cookie is an IP address and not a domain. Therefore, specifying a Domain attribute for that cookie is pointless, simply because an IP address doesn't have subdomains.
I have APIs deployed in 2 separate namespaces, admin.abc.com (original) and api.admin.abc.com (new). Upon completing login, a jwt cookie is set by the admin.abc.com site for .admin.abc.com. The cookie is for the Session, Secure and HttpOnly and it does not have any SameSite restrictions set. This cookie works well for all API calls to admin.abc.com.
Due to some new changes requiring some services to deployed separately, there are now services also deployed in the namespace api.admin.abc.com. I have a status page that gives me information about the services, memory, etc. and it works fine for the original namespace. But when I add in a status call to the second namespace, no cookies are passed along and the call fails authentication. However, if I open the URL in another tab in my browser, the cookies are passed to the backend and the call succeeds.
I've looked into setting my own cookies in the header during the request after retrieving the jwt's value. This fails for 2 reasons: 1) I don't believe I can access the jwt's value as the cookie is HttpOnly, and 2) I can't set a cookie in the HttpHeader options. I get a "Refused to Set Unsafe Header" error in the console if I try. If I turn on 'withAuthorization:true', it does set it (but still prints the error) and then actually gets a CORS error.
If I manually disable the HttpOnly flag on the cookie using EditThisCookie extension, the calls work successfully. I don't really think it's an option for me with my company's security, but it technically works.
I know some suggest sending the jwt as an Authorization: Bearer token, which I would do, but because the cookie is HttpOnly, I can't retrieve the value and programmatically set it. Additionally there is another site-wide cookie I'd like to send over at times that I can't really switch to some custom header.
Thoughts on what I can do? Is it not possible? My only other option is that all requests to the new namespace have to be routed through an API built in the old namespace.
I am working on RESTful SPA app using angularJS. Currently initial REST call is setting a "token" cookie on xyz.com ( secured response cookie) after successful user login. I am not able to read this cookie in Javascript/angular as I am working on localhost.
What I understood here , unless I run this app from xyz.com , i wont be able to access this cookie OR do I need a secured connection ?
Is my Understanding correct ?
Secondly, my understanding about "httponly" cookie is that , it wont be accessible from javascript even though you are on same host.
Please correct my understanding.
As the author of a website:
You cannot read a cookie for a different site (ever)
You cannot read an HTTP Only cookie with JavaScript
You cannot read a Secure cookie unless it is served over HTTPS
That's three separate conditions, with independent effects, and none, some or all of them can apply to any given cookie.
Therefore if a cookie is secure and for a different site then you can't read it no matter if you use HTTPS or not (since different site blocks you even if secure does not).
Question originally posted on Webmasters, was recommended to move it here.
I host a webservice, and provide my members with a Javascript bookmarklet, which loads a JS sript from my server. However, clients must be logged in, in order to receive the JS script. This works for almost everybody. However, some users on setups (i.e. browser/OS) that are known to work for other people have the following problem: when they request the script via the javascript bookmarklet from my server, their cookie from my server does not get included with the request, and as such they are always "not authenticated".
I'm making the request in the following way:
var myScript = eltCreate('script');
myScript.setAttribute('src','http://myserver.com/script');
document.body.appendChild(myScript);
In a fit of confused desperation, I changed the script page to simply output "My cookie has [x] elements" where [x] is count($_COOKIE) on http://myserver.example.com. If this subset of users requests the script using the above method encoded in the bookmarklet, the message reads "My cookie has 0 elements". When they access the URL directly in their browser, the message reads "My cookie has 7 elements".
What on earth could be going on?! And more importantly, how would I fix this?
I'm pretty sure this is a privacy setting issue. The affected browsers probably have increased their privacy settings refusing 3rd party scripts from setting cookies.
I've experience similar issues when placing an IFRAME pointing to domain B on a site hosted on domain A. Some browsers refused that my IFRAME set cookies for it's own domain because it triggered a privacy issue.
You might want to store a hash in the script src attribute and have it authenticate users that way.
Edit: This is sort of what I'm talking about: Setting cross-domain cookies in Safari
Please, I would like to set cookies for my browser by my script running at my domain.. but I want to set cookies from another domain.
For example, I would like to set cookies that twitter.com sends me (when I would visit by browser), but I don't want to visit their page for the first time. Only when I visit their page after running my script, I want that their cookie is already set. Is it possible at all?
I thought, that changing the domain variable for document.cookie is doing the trick, but it doesn't work.. the twitter doesn't see any cookie being set.
No you can't obviously. Being able to control cookies from domains other than the one your website/webapplication runs on, would be a tremendous security risk. Because being able to set, would also mean being able to read.
You can, but it requires some hacks and can't be done in javascript alone.
Open up firefox and grab your "auth_token" cookie from twitter.com
If you have access to a web server and can config it to accept all host headers.
Makeup a fake subdomain and add it to your hosts file like:
127.0.0.1 xxxxxxx.twitter.com
from that server set a cookie named "auth_token" with *.twitter.com as the domain.
This would work for twitter because their auth_cookie is set to expire in 20 years.