[DEVELOPMENT] - All fine (no issues as cookies are set on same domain 'localhost')
[PROD / LIVE] - Link below
The issue: The cookie are not being set properly or not getting persisted, I don't know why so if anyone can give me an idea what might be the cause as you can see in network tab, it sets the cookie but it doesn't put it in Application > Storage > Cookies you can have a look if I am not explaining it very well.
https://gta-open-q99pjtak6-patricksubang.vercel.app/
username: demo
password: demo
Front end, POST/GET request
const sendRequest = async (method, endpoint, custom) => {
const isProd =
process.env.NODE_ENV === "development"
? "http://localhost:8000/"
: "https://gta-open.ga/";
const url = isProd + endpoint;
const response = await fetch(url, {
method: method,
mode: "cors",
credentials: "include",
...custom,
});
return response;
};
Setting session cookie using gorrilla\sessions
Cookie.Options.Path = "/"
Cookie.Options.HttpOnly = true
Cookie.Options.SameSite = http.SameSiteNoneMode
state := false
if os.Getenv("ENV") == "PROD" {
state = true
}
Cookie.Options.Secure = state
func GenerateSession(w http.ResponseWriter, r *http.Request, uid int) (err error) {
session, _ := Cookie.Get(r, "sessionid")
session.Values["accountID"] = uid
// Save it before we write to the response/return from the handler.
err = session.Save(r, w)
if err != nil {
return
}
return
}
If anyone can give me a rough idea why, or the cause of the issue would be helpful
Many thanks!
Not familiar with a Golang backend nor gorrilla sessions, but I'm pretty sure it's how you're configuring your cookie settings. Specifically, I believe the domain name being set to gta-open.ga doesn't match vercel.app so it's either being blocked by the browser's third party cookie settings or not being utilized because the domain names don't match.
For example, cookie blocked by 3rd party (user's browser preference):
As a result, no cookie is set:
However, if I allow 3rd party cookies from cross-domains, then the cookie is set:
However, since it has a different domain from the app, it's not being utilized:
On that note, I'd highly suggest purchasing your own domain. They're pretty cheap (10usd/7gbp or less per year), then you can set up your vercel app to use the custom domain. Then, set your cookie to use that custom domain name and it should be smooth sailing.
Otherwise, you'll have to set up the cookie to use subdomain's .vercel.app in production (which isn't recommended because vercel hosts a lot of apps on their subdomains) or use domain gta-open-q99pjtak6-patricksubang.vercel.app, but that's kind of silly.
Related
The error occurs in this react code
const headers = new Headers({
"X-CSRFToken": Cookies.get('csrftoken')
});
const response = await fetch("api/signinUser",
{
method: "POST",
headers: headers,
body: formData
});
Trying to access this Django Api
#ensure_csrf_cookie
def signin(request):
if request.method == 'POST':
auth = False
username = request.POST['username']
password = request.POST['password']
user = authenticate(username=username, password=password)
print("Authenticating User", user)
if user is not None:
auth = True
login(request, user) # Does this return anything?
ret = {
"auth": auth
}
print("RET", ret)
return JsonResponse(ret)
I have django.middleware.csrf.CsrfViewMiddleware in my MIDDLEWARE variable
I'm running my Django server in an AWS EC2 instance that I access with http://<my public ip>:8000/
headers: {
'X-Requested-With': 'XMLHttpRequest',
'csrftoken': Cookies.get('csrftoken'),
},
As you are accessing using HTTP (and not https) you need to ensure the cookies are not https only (i.e. "Secure").
The "easiest" for this it to changes your settings to ensure that http cookies will work (https://docs.djangoproject.com/en/4.1/ref/settings/#csrf-cookie-httponly, https://docs.djangoproject.com/en/4.1/ref/settings/#csrf-cookie-secure and https://docs.djangoproject.com/en/4.1/ref/settings/#session-cookie-httponly).
However, as you're on AWS, it's fairly easy and cheap to access over HTTPS with a valid certificate if you have a (sub)domain name you can use.
Create yourself a Load Balancer (in the EC2) panel). That prompts you to...
Create a "Target Group". The target group contains the instance above
Set it so that a listener on "443" will redirect traffic to "80" on your instance (so your instance does not need a certificate). In doing this, you'll be prompted to create a certificate within AWS.
Point your DNS to the load balancer.
Please check costs, but the normally-expensive part (the certificate) is free, and you can set security groups to lock users our of having direct access to your EC2.
You should check out the docs.
https://docs.djangoproject.com/en/4.1/ref/csrf/
A hidden form field with the name ‘csrfmiddlewaretoken’, must be present in all outgoing POST forms.
They are referring to a hidden input field within your form.
For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or TRACE, a CSRF cookie must be present, and the ‘csrfmiddlewaretoken’ field must be present and correct. If it isn’t, the user will get a 403 error.
I'm implementing an auth system with django and react. The two app run respectively on port 8000, 3000. I have implemented the authentication system using the Djoser package. This package uses some dependencies social_core and social_django. Everything seems to be configured ok. I click on login google button...I'm redirected to the google login page and then back to my front-end react app at port 3000 with the state and code parameters on the url.
At this point I'm posting those parameters to the backend. The backend trying to validate the state checking if the state key is present in the session storage using the code below from (social_core/backends/oauth.py)
def validate_state(self):
"""Validate state value. Raises exception on error, returns state
value if valid."""
if not self.STATE_PARAMETER and not self.REDIRECT_STATE:
return None
state = self.get_session_state()
request_state = self.get_request_state()
if not request_state:
raise AuthMissingParameter(self, 'state')
elif not state:
raise AuthStateMissing(self, 'state')
elif not constant_time_compare(request_state, state):
raise AuthStateForbidden(self)
else:
return state
At this point for some reasons the state session key is not there..and I receive an error saying that state cannot be found in session data ( error below )
{"error":["State could not be found in server-side session data."],"status_code":400}
I recap all the action I do:
Front-end request to backend to generate given the provider google-oauth2 a redirect url. With this action the url is generated also the state key is stored on session with a specific value ( google-oauth2_state ).
Front-end receive the url and redirect to google auth page.
Authentication with google and redirection back to the front-end with a state and code parameters on the url.
Front-end get the data form url and post data to back-end to verify that the state received is equal to the generated on the point (1).
For some reasons the state code is not persisted... Any ideas and help will be really appreciated.
Thanks to all.
ok so this is a common problem while you are working with social auth. I had the same problem for so many times.
The flow:
make a request to http://127.0.0.1:8000/auth/o/google-oauth2/?redirect_uri=http://localhost:3000/ (example)
you will get a authorization_url. if you notice in this authorization_url there is a state presented . this is the 'state of server side'.
now you need to click the authorization_url link.Then you will get the google auth page.After that you will be redirect to your redirect url with a state and a code. Remember this state should be the same state as the server side state .(2)
make post req to http://127.0.0.1:8000/auth/o/google-oauth2/?state=''&code=''.
if your states are not the same then you will get some issue.
everytime you wanna login , you need to make a request to http://127.0.0.1:8000/auth/o/google-oauth2/?redirect_uri=http://localhost:3000/
and then to http://127.0.0.1:8000/auth/o/google-oauth2/?state=''&code='' thus you will get the same state.
Without necessary detailed information, I can only tell 2 possible reasons:
You overrode backend with improper session operations(or the user was logged out before auth was finished).
Front-end used incorrect state parameter
You could test social login without front-end, let's say if you're trying to sign in with Google:
Enter the social login URL in browser, like domain.com:8000/login/google-oauth2/
Authorize
See if the page redirected to your default login page correctly
If yes, then probably you need to check your front-end code, and if no, then check your backend code.
At the end, if you're not so sensitive to the potential risk, you could also override GoogleOAuth2 class as following to disable state check:
from social_core.backends import google
class GoogleOAuth2(google.GoogleOAuth2):
STATE_PARAMETER = False
I think you may need some changes in you authorizing flow in step NO.3 and 4.
3.Authentication with google and redirection back to the front-end with a state and code parameters on the url.
4.Front-end get the data form url and post data to back-end to verify that the state received is equal to the generated on the point (1).
maybe you should redirect back to server side after google's authorization.
then at the server side, do the check! validate the state and code (maybe do more things).
then let server redirect to the front-end site you wanted to before.
for some reason, redirect to front-end directly will miss the param.. :-)
Finally, I reach a point where everything is working 200 percent fine, on local as well as production.
The issue was totally related to the cookies and sessions:
So rite answer typo is
make it look to your backend server as if the request is coming from localhost:8000, not localhost:3000,
means the backend domain should be the same always.
For making it possible you have two ways:
1: server should serve the build of the frontend then your frontend will always be on the same domain as the backend.
2: make a simple view in django and attach an empty template to it with only a script tag including logic to handle google auth. always when you click on signing with google move back you you're that view and handle the process and at the end when you get back your access token pass it to the frontend through params.
I used 2nd approach as this was appropriate for me.
what you need to do is just make a simple View and attach a template to it so on clicking on signIN with google that view get hit. and other process will be handled by the view and on your given URL access token will be moved.
View Code:
class GoogleCodeVerificationView(TemplateView):
permission_classes = []
template_name = 'social/google.html'
def get_context_data(self, **kwargs):
context = super().get_context_data(**kwargs)
context["redirect_uri"] = "{}://{}".format(
settings.SOCIAL_AUTH_PROTOCOL, settings.SOCIAL_AUTH_DOMAIN)
context['success_redirect_uri'] = "{}://{}".format(
settings.PASSWORD_RESET_PROTOCOL, settings.PASSWORD_RESET_DOMAIN)
return context
backend script code:
<body>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.21.1/axios.min.js"></script>
<script>
function redirectToClientSide(success_redirect_uri) {
window.location.replace(`${success_redirect_uri}/signin/`);
}
function getFormBoday(details) {
return Object.keys(details)
.map(
(key) =>
encodeURIComponent(key) + "=" + encodeURIComponent(details[key])
)
.join("&");
}
try {
const urlSearchParams = new URLSearchParams(window.location.search);
const params = Object.fromEntries(urlSearchParams.entries());
const redirect_uri = "{{redirect_uri|safe}}";
const success_redirect_uri = "{{success_redirect_uri|safe}}";
if (params.flag === "google") {
axios
.get(
`/api/accounts/auth/o/google-oauth2/?redirect_uri=${redirect_uri}/api/accounts/google`
)
.then((res) => {
window.location.replace(res.data.authorization_url);
})
.catch((errors) => {
redirectToClientSide(success_redirect_uri);
});
} else if (params.state && params.code && !params.flag) {
const details = {
state: params.state,
code: params.code,
};
const formBody = getFormBoday(details);
// axios.defaults.withCredentials = true;
axios
.post(`/api/accounts/auth/o/google-oauth2/?${formBody}`)
.then((res) => {
const formBody = getFormBoday(res.data);
window.location.replace(
`${success_redirect_uri}/google/?${formBody}`
);
})
.catch((errors) => {
redirectToClientSide(success_redirect_uri);
});
} else {
redirectToClientSide(success_redirect_uri);
}
} catch {
redirectToClientSide(success_redirect_uri);
}
</script>
</body>
I've made a simple project in React; the client is running at port 3000, server at 3001.
If I launch localhost:3001/api/visitator/cars it works correctly, but when I make the GET Request on Client I have this error, on console http://localhost:3000/api/visitator/cars 404 (Not found).
I don't know why, but the request is done on port 3000 and not 3001, even if on package.json is present
"proxy": "http://localhost:3001".
This is the code in client/api:
async function askForCars(){
let url = '/api/visitator/cars'
const response = await fetch(url);
const carJson = await response.json();
if(response.ok){
console.log(carJson)
return carJson;
} else {
let err = {status: response.status, errObj:carJson};
throw err; // An object with the error coming from the server
}
}
There are two ways to solve this:
You have give the full path rather than relative path as your server lies on a different domain as ports are different. So your url variable value should be the domain name + uri + i.e. http://localhost:3001/api/visitator/cars.
The second way to solve this would be you need to add redirect rules on the server where you are hosting the app so that your every request having http://localhost:3000/api uri should be redirected to http://localhost:3001/api.
I think the quick solution would be the first one for now incase you don't have requirement to redirect api calls to actual server. Hope it helps.
I'm trying to pull some data into a Google sheets spreadsheet from an API that's been built using Google Cloud Endpoints. Here is the API declaration:
#Api(
name = "myendpoint",
namespace =
#ApiNamespace
(
ownerDomain = "mydomain.com",
ownerName = "mydomain.com",
packagePath = "myapp.model"
),
scopes = {SCOPES},
clientIds = {ANDROID_CLIENT_ID, WEB_CLIENT_ID, API_EXPLORER_CLIENT_ID},
audiences = {WEB CLIENT_ID}
)
The method I'm trying to access has authentication enabled by means of the user parameter in the API declaration:
#ApiMethod(name = "ping", httpMethod = HttpMethod.GET, path = "ping")
public StringResponse getPing(User user) throws OAuthRequestException {
CheckPermissions(user);//throws an exception if the user is null or doesn't have the correct permissions
return new StringResponse("pong");
}
This works fine when using the generated client libraries or the gapi js library. However AFAIK I can't use those js libraries in Apps Script.
I've got an OAuth2 flow working using the apps-script-oauth2 library from here, and I'm pretty much using the default setup for creating the service
function getService() {
// Create a new service with the given name. The name will be used when
// persisting the authorized token, so ensure it is unique within the
// scope of the property store.
return OAuth2.createService(SERVICE_NAME)
// Set the endpoint URLs, which are the same for all Google services.
.setAuthorizationBaseUrl('https://accounts.google.com/o/oauth2/auth')
.setTokenUrl('https://accounts.google.com/o/oauth2/token')
// Set the client ID and secret, from the Google Developers Console.
.setClientId(CLIENT_ID)
.setClientSecret(CLIENT_SECRET)
// Set the name of the callback function in the script referenced
// above that should be invoked to complete the OAuth flow.
.setCallbackFunction('ruggedAuthCallback')
// Set the property store where authorized tokens should be persisted.
.setPropertyStore(PropertiesService.getUserProperties())
// Set the scopes to request (space-separated for Google services).
.setScope(SCOPES)
// Below are Google-specific OAuth2 parameters.
// Sets the login hint, which will prevent the account chooser screen
// from being shown to users logged in with multiple accounts.
.setParam('login_hint', Session.getActiveUser().getEmail())
// Requests offline access.
.setParam('access_type', 'offline')
// Forces the approval prompt every time. This is useful for testing,
// but not desirable in a production application.
.setParam('approval_prompt', 'auto')
//.setParam('include_granted_scopes', 'true');
}
These are my methods for accessing the APIs
function getDriveDocs() {
return executeApiMethod('https://www.googleapis.com/drive/v2/','files?maxResults=10');
}
function pingServer(){
return executeApiMethod('https://myapp.appspot.com/_ah/api/myendpoint/v1/','ping');
}
function executeApiMethod(apiUrl, method)
{
//var url = ;
var url = apiUrl + method;
var service = getRuggedService();
return UrlFetchApp.fetch(url, {
'muteHttpExceptions': true,
'method': 'get',
'headers': {
Authorization: 'Bearer ' + service.getAccessToken()
}
});
}
The getDriveDocs() method works perfectly, so I know my auth flow is working correctly. Also, if I call an unauthenticated method in my API I get the correct response. However, when I call the authenticated 'ping' method, the 'user' parameter is always null. Am I missing something in the fetch call? Everything I've read so far seems to suggest that setting
Authorization: 'Bearer ' + service.getAccessToken()
should be enough.
Any help would be much appreciated!
This turned out to be a simple mistake - I had created a new oauth2 credential in the google dev console and had not added the new client id to the API declaration. Here is the working API declaration:
#Api(
name = "myendpoint",
namespace =
#ApiNamespace
(
ownerDomain = "mydomain.com",
ownerName = "mydomain.com",
packagePath = "myapp.model"
),
scopes = {SCOPES},
clientIds = {ANDROID_CLIENT_ID, WEB_CLIENT_ID, API_EXPLORER_CLIENT_ID, GAPPS_CLIENT_ID},
audiences = {WEB CLIENT_ID}
)
I have implemented OWIN token based authentication on my WebApi, I have also enabled CORS by calling app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll)
I can access various unsecured portions of my app from an angularjs web client. I have used this http-interceptor , when I try to access a protected resource, I get my login pop.
Now in order to login I have to call http://mywebapi/token with form encoded UserName Password and grant_type, see my header signature below (from chrome)
Request URL:http://mywebapi/token
Request Headers CAUTION: Provisional headers are shown.
Accept:application/json, text/plain, */*
cache:false
Content-Type:application/x-www-form-urlencoded
Origin:http://127.0.0.1:49408
Referer:http://127.0.0.1:49408/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Form Dataview sourceview URL encoded
grant_type:password
UserName:correctuser
Password:Password
When I use postman to send this request, it comes back fine with the expected accesstoken, however when I try to use angular's $http service, it makes the OPTIONS request (I can see this in Dev tools console) but for some reason I get this error message
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:49408' is therefore not allowed access.
NOTE: This only happens for the /token request which is form-url-encoded, for all other json requests the header is added as expected. Can someone please help, I am running out of ideas.
Thanks
I went through the same process and spend (wasted?) the same amount of time as most people, dealing with owin + web api.
A solution which worked for me was to move
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
before everything else in the pipe.
Here is some code:
OwinStartup
[assembly: OwinStartup(typeof(MyApp.Web.Startup))]
namespace MyApp.Web
{
using Owin;
using Microsoft.Owin;
public partial class Startup
{
public void Configuration(IAppBuilder app)
{
var config = new System.Web.Http.HttpConfiguration();
ConfigureAuth(app, config);
}
}
}
Startup for OAuth
public partial class Startup
{
public void ConfigureAuth(IAppBuilder app, System.Web.Http.HttpConfiguration config)
{
// app.UseWelcomePage("/");
// app.UseErrorPage();
// Must be the first to be set otherwise it won't work.
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
app.CreatePerOwinContext<ApplicationDatabaseContext>(ApplicationDatabaseContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.UseOAuthBearerAuthentication(new OAuthBearerAuthenticationOptions());
var OAuthOptions = new OAuthAuthorizationServerOptions
{
AllowInsecureHttp = true,
TokenEndpointPath = new PathString("/token"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
Provider = new DaufAuthorizationServerProvider(),
RefreshTokenProvider = new SimpleAuthorizationServerProvider(),
};
app.UseOAuthAuthorizationServer(OAuthOptions);
app.UseWebApi(WebApiConfig.Register(config, logger));
}
}
Web Api
public static class WebApiConfig
{
public static HttpConfiguration Register(System.Web.Http.HttpConfiguration config, ILogger logger)
{
// Web API configuration and services
// Configure Web API to use only bearer token authentication.
// This will used the HTTP header: "Authorization" Value: "Bearer 1234123412341234asdfasdfasdfasdf"
config.SuppressDefaultHostAuthentication();
config.Filters.Add(new HostAuthenticationFilter(OAuthDefaults.AuthenticationType));
// Web API routes
config.MapHttpAttributeRoutes();
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
return (config);
}
}
So I found the answer but brace yourself 'coz this one's weird!! I read this article on code project which led me to my Owin Authorisation server's GrantResourceOwnerCredentials method to check for this
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
(Mine is a custom Authoris(z)ation server, one I nicked off here)
The shocking thing I found was that it was already there!
So I decided to set a break point on that line and what do you know, that line was failing because (...even more shocking) "Access-Control-Allow-Origin" was already in the headers!!
So I commented that line out and it all worked! But then the caveat, I have no idea how the header got in, so I have no idea if it will be there or not in production so I swapped that line of code with this to check and then add it if it was not already there
var header = context.OwinContext.Response.Headers.SingleOrDefault(h => h.Key == "Access-Control-Allow-Origin");
if (header.Equals(default(KeyValuePair<string, string[]>)))
{
context.OwinContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { "*" });
}
I hope my labour of love will save a few souls from the excruciating damnation of countless hours of tinkering with nothing to solve this problem. Cheers!
For those curious about the answer and the previous answer, it is indeed strongly related the ordering. Whenever you are adding Owin middleware it is important to note: The order of registration is imperative.
app.useCors(Microsoft.Owin.Cors.CorsOptions.AllowAll)
Having this as the first thing in your auth file, basically registers the Cors handler to occur prior to reaching your OAuthServer and Web Api.
Moving it after the OAuth does the opposite, hence the need to add the Access-Control-Allow-Origin header in the GrantResourceOwnerCredentials.
To answer the other question, the reason the header is already there is if you send a CORS request from the browser and the CorsOptions.AllowAll is specified, it adds one for you so by the time it reaches the /token endpoint on the OAuth server it has already added one. (just means that one was found in the http request and you are allowing all origins).
You can verify the behaviours accordingly,
In Fiddler, send a new request to your Token endpoint with an Origin header included with an arbitrary value. Put a breakpoint on your OAuth server in the GrantResourceOwnerCredentials and then examine context.Response.Headers, it will now contain the origin you passed in. (Remember, the browser must examine it, fiddler will be happy all day long)
If you then tell CORS not to use CorsOptions.AllowAll and set AllowAnyOrigin to false you will notice that the Origin sent from Fiddler is no longer added to the response headers.
The browser in turn will deny the CORS request because the origin was not returned - Origin "" not found in Access-Control-Allow-Origin header.
NOW FOR THE IMPORTANT BIT:
If you set CorsOptions.AllowAll it does exactly what it says it does, allows CORS requests to any method on any middleware that occurs after the CORS registration in the Owin pipeline so make sure that is what you intend to do. IE: If you register CORS first then OAuth and Web API then all your Web API methods will be accessible via CORS if you do not explicitly add code\attributes to prevent it.
If you want to restrict the methods then implement an ICorsPolicyProvider, some portions from http://katanaproject.codeplex.com/(Microsoft.Owin.Cors)
public class MyCorsPolicyProvider : ICorsPolicyProvider
{
public Task<CorsPolicy> GetCorsPolicyAsync(IOwinRequest request)
{
// Grant Nothing.
var policy = new CorsPolicy
{
AllowAnyHeader = false,
AllowAnyMethod = false,
AllowAnyOrigin = false,
SupportsCredentials = false
};
// Now we can get a bit clever: (Awesome, they requested the token endpoint. Setup OAuth options for that.
if (OAuthOptions.TokenEndpointPath.HasValue && OAuthOptions.TokenEndpointPath == request.Path)
{
// Hypothetical scenario, tokens can only be obtained using CORS when the Origin is http://localhost
policy.AllowAnyHeader = true;
policy.AllowAnyMethod = true;
policy.AllowAnyOrigin = false;
policy.SupportsCredentials = true;
policy.Origins.Add("http://localhost");
return Task.FromResult(policy);
}
// No token?, must already have one.... so this must be a WebApi request then.
// From here we could check where the request is going, do some other fun stuff etc... etc...
// Alternatively, do nothing, set config.EnableCors() in WebApi, then apply the EnableCors() attribute on your methods to allow it through.
return null; }
}
The return null; tells Owin to continue to the next middleware and to allow the request through but with no policy thus NO CORS!, allowing you to set appropriate CORS attributes in WebAPI
Now the really important bit, DO NOT add the Access-Control-Allow-Origins header to your response if it is not there unless that is really what you intend as depending on your middleware registration order it will open all the doors for CORS requests unless you explicitly block them elsewhere or remove the header and basically will cause you lots of issues when you try and use CORS with WebApi and want to restrict it.
To block them elsewhere you could add a CorsPolicyProvider (System.Web.Http) for WebApi then set a Context variable in Owin which you can read once the request hits WebApi.
public class WebApiCorsPolicyProvider : System.Web.Http.Cors.ICorsPolicyProvider
{
public Task<CorsPolicy> GetCorsPolicyAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
var policy = new CorsPolicy
{
AllowAnyHeader = false,
AllowAnyMethod = false,
AllowAnyOrigin = false,
SupportsCredentials = false
};
// The benefit of being at this point in the pipeline is we have been authenticated\authorized so can check all our claims for CORS purposes too if needed and set errors etc...
// In an Owin pipeline?
var owinContext = request.GetOwinContext();
if (owinContext != null)
{
// We have an owin pipeline, we can get owin parameters and other things here.
}
else
{
// Write your code here to determine the right CORS options. Non Owin pipeline variant.
}
return Task.FromResult(policy);
}
}
And finally, one other benefit of propagating downwards to a WebApi CORS policy provider is that at that point Authorization will have taken place so you can then apply additional Origin filters at that stage in the CORS policy provider.
In my opinion it is related to ordering of your statements though I did not investigated further. I faced the same issue and tried all combinations and eventually following worked for me.
public void Configuration(IAppBuilder app)
{
HttpConfiguration config = new HttpConfiguration();
ConfigureOAuth(app);
WebApiConfig.Register(config);
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
app.UseWebApi(config);
}
I was following Token Based Authentication using ASP.NET Web API 2, Owin, and Identity
This is another version of the code for the Obi Onuorah's response
string corsHeader = "Access-Control-Allow-Origin";
if (!context.Response.Headers.ContainsKey(corsHeader))
{
context.Response.Headers.Add(corsHeader, new[] { "*" });
}