I'm developing a spring-boot based backend app and an angularjs based frontend app hosted on the same domain with different subdomains.
myapp-frontend.mydomain.com //my angularjs app
myapp-backend.mydomain.com //my spring-boot app
otherapp-frontend.mydomain.com //some existing app running on same domain but unrelated
I'm trying to set the cookie which contains the jwt token generated in the backend to the browser when login api is called from the angularjs.
Cookie is set into browser with this code when I set the base domain url in spring-boot:
Cookie cookie = new Cookie("Authentication", jwt);
cookie.setPath("/");
cookie.setDomain("mydomain.com"); //this works
response.addCookie(cookie);
This set the cookie for other apps hosted on our company domain, but doesn't share user credentials with my app. Since I want the Authentication cookie header to be visible only to my frontend app, I tried to set the frontend subdomain url in the code. But this doesn't work.
...
cookie.setDomain("myapp-frontend.mydomain.com"); //not setting cookie
...
I understand that cookie cannot be set across different domains for security reasons but why is setting the subdomain url not working?
Out of curiosity, I tried putting backend subdomain in the setDomain() and cookie is set under myapp-backend.mydomain.com when I checked in chrome developer tools. Since it's working with base domain url, I believe I have already implemented the CORS correctly.
Am I missing something here? Any input would be greatly appreciated.
Related
I want to use Nuxt.js for my frontend and laravel sanctum as my backend authentication provider. How should I set the SESSION_DOMAIN key in the .env file in my laravel project.
Also should I edit anything in the server object part in the nuxt.config.js file to make this work?
When you use Sanctum with SPA, such as Nuxt, you've the option to use either API or cookies/sessions. If your application is a first-party application on same top level domain, Laravel recommends to use cookie based approach so you can take advantage of CSRF protection. Axios and Angular Http libraries handles CSRF out of the box, so you don't have to worry too much about handling the requests headers [1].
In your case, I assume your application is first party and is on same top level domain. So your SESSION_DOMAIN value would be for example .domain.com. Also you'll need to set SANCTUM_STATEFUL_DOMAINS=domain.com as well. Usually your SESSION_DOMAIN will have just the main domain your application uses on, while SANCTUM_STATEFUL_DOMAINS will have all the subdomains (if any), that your frontend uses.
To work with Sanctum, we should be familiar with a few things first. We must use our SPA and API backend on the same domain, like frontend on domain.com and API on api.domain.com. We can not set frontend on domain.com and backend (API) on another-domain.com. The client must be able to include cookies with each request being sent to the backend.
session domain is the front-end domain name without protocol and port.
When you are working on local you must set it to localhost and when you are working on server you must set the domain name.
please follow this example of nuxt-laravel-sanctum-auth
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've added the client id and secret to the yml configuration file, but it's not working. When I try to login with one of the providers, it redirects me to a blank page with the message 'cannot POST /signin/google', if I try to login with Google, for example. I generated a monolith application with JWT authentication and social login feature (I'm using Angular 2+).
Maybe you should check https://console.developers.google.com/apis/credentials and set properly your Authorised JavaScript origins and Authorised redirect URIs. First one should be set to just for example http://localhost and second one must contain several entries for example
http://localhost:8080
http://localhost:8080/signin
http://localhost:8080/signin/google
I would like to use my API website for authentication & authorisation of users and ideally keep my UI site purely static content (html, js, css).
I have configured ServiceStack's OAuth & OpenId (and credential/basic) providers, so they answer to api.mysite.com/auth/{provider} requests
I would like to be able to users of www.mysite.com to be able to authenticate and then make calls to the API site via ajax.
The BootstrapApi example project - although very useful - demonstrates the API & website running on the same domain.
Is this possible/secure with a static javascript client?
Could I share a cookie between sub-domains?
Could I return the access token to the client and have use it to calculate an Authorization header before each request?
To address your questions -
Is this possible/secure with a static javascript client? Yes
Could I share a cookie between sub-domains? Yes
Could I return the access token to the client and have use it to calculate an Authorization
header before each request? Sure but you may as well just use the
built in auth cookie.
It's just a matter of setting up your cookies on the top level domain, similar to what's shown # ServiceStack - Authentication for domain and subdomains
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.