The previous video, when we are trying to make a communication with the backend server from our white
angular application, we got an error indicating cause coarse means cross origin resource sharing.
That means applications with two different origins.
They're trying to communicate with each other to try to see what is coarse in detail in this video course
is a protocol that enables scripts running on a browser claim to interact with the resources from different
orison, for example, if it Untappd, which is to make an API call, running on a different domain
to different domain can be a different hostname, different board member.
It would be blocked by default due to cost policy in all the processes that we are using today.
So course, as we think it's not a security attack or security issue, it's the default protection provided
by our browsers so that applications which are hosted in two different host are boards are two different
domain names, will be stopped communicating with each other.
So that's a default behavior.
So when we say autism, autism means it can be a Street-Porter history tips and domain name.
And what, if any, services or applications which differ in any of these three parameters like history,
restrictive protocol, domain name or no, they will be treated as cross origin, that these two different
applications are not belongs to the same origin.
Like you've seen the diagram you app, which has a domain name as domain one.
It's trying to consume a service which is hosted on Domain 2.0.
So since this is satisfying cost policy by default, browser will stop the communication between these
two applications.
Indicating that there might be a security breach may happen, but it might be a very valid reason why
two different applications hoster are two different.
Supersport needs to communicate in any application, particularly this is most frequent approach in
Microsoft.
We suspected long back when we are used to build our application in monolithic approach where everything
is deployed into a single server like both your UI pages back and the services, everything stays on
the same post, on same bottom, so that there is no problem of cost.
But these days, when we are building application using Microsoft Services pattern where the services
will be hosted somewhere, your UI application will be hosted somewhere your mobile application will
be hosted in the play store.
So in all the scenarios, there is a good chance cost policy will come into feature and will stop your
communication.
But you have a very valid reason to communicate because all those are your applications and you don't
want the browser to stop that communication due to cost policy to work on the challenge.
Whatever the backend server that is trying to share the data to the UK has to configure it properly
so that cross will be accepted by your browser.
So this can be achieved by making simple configurations on the backend with the following properties.
So one of the properties that you have to set is access control.
So this is the property where you are telling request and response.
Sharing from a particular person has to be shared and no cost restriction should be applied.
Starting to get that means any errors in or any application, any website can communicate with my back.
And so which is not recommended approach always clearly define your horsemen's what name instead of
start and you can also fine grained control like what restrictive methods Castroville look like.
Only get are only post in the course of design request.
We can also define headers credentials and maximum time that this cost policy has to be accepted by
caching the details inside the browser.
So when we define all these details on your server, then your browser since OK, my backend responded
with these details which are related to cause communication and it will start communicating with the
backend server without throwing in cost issue.
So it's very simple.
First, your browser will make a pre-flight request to the back end server whether the policy is allowed
of.
When you're back in server responded with all these parameters, OK, these are the origins that I want,
all of these are the methods, these are the best credentials your browser can understand.
OK, this communication between the U.K. and the backend application is approved by the backend and
it will not throw any cards ever.
So now we have complete clear idea of what is cross origin resource sharing issue.
Let's try to fix this issue using spring security framework and resolve the concern that we are getting
inside the application.
So as you can see, both our applications fall into two different origins because the port name is different.
The upshot that I have for two double zero and the back and forth that I have eight zero eight zero
is different.
That's why my browser is treating them as two different origins.
If I want the communication to happen definitely on the back inside, I have to make configurations
to parse all these parameters so that my browser can pass this communication and will not throw it out.
Let's try to make that change in that mix.
Really.
Thank you by.