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.
Related
[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.
When I place the below in a React component that queries the user model I am able to get the entire user object as queried by graphQL including the id property:
console.log(this.props.data.user)
But when I try to access the id property from code:
console.log(this.props.data.user) // undefined
console.log(this.props.data.user.id)
// error cannot get property of undefined
My first guess is that this is a security feature; I am using Auth0 and Graphcool.
But I may just be going about this in a backwards way. If so, any help on accessing the user id in the correct manner would be appreciated.
Thanks
This is covered in the FAQ article on the logged in user.
Obtaining a Signed JWT with Auth0
The user query returns the currently authenticated user. So first we have to think about how the authenticated user is determined.
The current state-of-the-art is using verified JWT and passing them as the Authorization header.
After entering valid credentials in Auth0 Lock, it returns a JWT that is signed with your secret Auth0 key. This signed JWT is sent to the GraphQL server where we'll use your Auth0 key to verify it and if it belongs to a valid user, the request is authenticated.
Setting the Authorization Header with Apollo Client
So I suspect that you're simply not passing a valid Authorization header. With Apollo, you can use this to ensure passing the token if it is present. Note that we'll use local storage for storing the token from Auth0 Lock:
const networkInterface = createNetworkInterface({ uri: 'https://api.graph.cool/simple/v1/__PROJECT_ID__' })
// use the auth0IdToken in localStorage for authorized requests
networkInterface.use([{
applyMiddleware (req, next) {
if (!req.options.headers) {
req.options.headers = {}
}
// get the authentication token from local storage if it exists
if (localStorage.getItem('auth0IdToken')) {
req.options.headers.authorization = `Bearer ${localStorage.getItem('auth0IdToken')}`
}
next()
},
}])
const client = new ApolloClient({ networkInterface })
Check this Auth0 example code or the live demo to see how it works.
You might also be interested in this answer on authorization (permissions).
I'm really confused how Google App Engine's User's get_current_user() works. I've looked around the internet at a bunch of different guides and tutorials about login and authentication, and many of them mention similar methods.
If there are a million users logged in to my application at the same time, how can that method possibly work? Does each user get their own instance of the server? How does the server know which client it is talking to?
It doesn't make sense to me at all.
When logging in (by clicking on the URL generated by create_login_url()) a cookie containing user identifying information is prepared and pushed on the client side, then used in subsequent requests until the user logs out or the cookie expires. Calling get_current_user() simply checks the cookie existance/information and responds accordingly.
On the development server the cookie is named dev_appserver_login. I can no longer check the cookie name on GAE as I switched away from the Users API.
The actual handling of the cookie seems to happen somewhere on the Users service backend, for example, by looking at the google/appengine/api/users.py file in the python SDK:
def create_login_url(dest_url=None, _auth_domain=None,
federated_identity=None):
...
req = user_service_pb.CreateLoginURLRequest()
resp = user_service_pb.CreateLoginURLResponse()
try:
apiproxy_stub_map.MakeSyncCall('user', 'CreateLoginURL', req, resp)
...
The end point (at least for the development server) seems to somehow land somewhere in google/appengine/tools/appengine_rpc.py, for example:
#staticmethod
def _CreateDevAppServerCookieData(email, admin):
"""Creates cookie payload data.
Args:
email: The user's email address.
admin: True if the user is an admin; False otherwise.
Returns:
String containing the cookie payload.
"""
if email:
user_id_digest = hashlib.md5(email.lower()).digest()
user_id = "1" + "".join(["%02d" % ord(x) for x in user_id_digest])[:20]
else:
user_id = ""
return "%s:%s:%s" % (email, bool(admin), user_id)
def _DevAppServerAuthenticate(self):
"""Authenticates the user on the dev_appserver."""
credentials = self.auth_function()
value = self._CreateDevAppServerCookieData(credentials[0], True)
self.extra_headers["Cookie"] = ('dev_appserver_login="%s"; Path=/;' % value)
I am trying to send a PUT request to an amazonS3 presigned URL. My request seems to be called twice even if I only have one PUT request. The first request returns 200 OK, the second one returns 400 Bad Request.
Here is my code:
var req = {
method: 'PUT',
url: presignedUrl,
headers: {
'Content-Type': 'text/csv'
},
data: <some file in base64 format>
};
$http(req).success(function(result) {
console.log('SUCCESS!');
}).error(function(error) {
console.log('FAILED!', error);
});
The 400 Bad Request error in more detail:
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>InvalidArgument</Code>
<Message>Only one auth mechanism allowed; only the X-Amz-Algorithm query parameter, Signature query string parameter or the Authorization header should be specified</Message>
<ArgumentName>Authorization</ArgumentName>
<ArgumentValue>Bearer someToken</ArgumentValue>
<RequestId>someRequestId</RequestId>
<HostId>someHostId</HostId>
</Error>
What I don't understand is, why is it returning 400? and What's the workaround?
Your client is probably sending an initial request that uses an Authorization header, which is being responded with a 302. The response includes a Location header which has a Signature parameter. The problem is that the headers from the initial request are being copied into the subsequent redirect request, such that it contains both Authorization and Signature. If you remove the Authorization from the subsequent request you should be good.
This happened to me, but in a Java / HttpClient environment. I can provide details of the solution in Java, but unfortunately not for AngularJS.
For the Googlers, if you're sending a signed (signature v4) S3 request via Cloudfront and "Restrict Bucket Access" is set to "Yes" in your Cloudfront Origin settings, Cloudfront will add the Authorization header to your request and you'll get this error. Since you've already signed your request, though, you should be able to turn this setting off and not sacrifice any security.
I know this may be too late to answer, but like #mlohbihler said, the cause of this error for me was the Authorization header being sent by the http interceptor I had setup in Angular.
Essentially, I had not properly filtered out the AWS S3 domain so as to avoid it automatically getting the JWT authorization header.
Also, the 400 "invalid argument" may surface as a result of wrong config/credentials for your S3::Presigner that is presigning the url to begin with. Once you get past the 400, you may encounter a 501 "not implemented" response like I did. Was able to solve it by specifying a Content-Length header (specified here as a required header). Hopefully that helps #arjuncc, it solved my postman issue when testing s3 image uploads with a presigned url.
The message says that ONLY ONE authentication allowed. It could be that You are sending one in URL as auth parameters, another - in headers as Authorization header.
import 'package:dio/adapter.dart';
import 'package:dio/dio.dart';
import 'package:scavenger_inc_flutter/utils/AuthUtils.dart';
import 'package:scavenger_inc_flutter/utils/URLS.dart';
class ApiClient {
static Dio dio;
static Dio getClient() {
if (dio == null) {
dio = new Dio();
dio.httpClientAdapter = new CustomHttpAdapter();
}
return dio;
}
}
class CustomHttpAdapter extends HttpClientAdapter {
DefaultHttpClientAdapter _adapter = DefaultHttpClientAdapter();
#override
void close({bool force = false}) {
_adapter.close(force: force);
}
#override
Future<ResponseBody> fetch(RequestOptions options,
Stream<List<int>> requestStream, Future<dynamic> cancelFuture) async {
String url = options.uri.toString();
if (url.contains(URLS.IP_ADDRESS) && await AuthUtils.isLoggedIn()) {
options.followRedirects = false;
options.headers.addAll({"Authorization": await AuthUtils.getJwtToken()});
}
final response = await _adapter.fetch(options, requestStream, cancelFuture);
if (response.statusCode == 302 || response.statusCode == 307) {
String redirect = (response.headers["location"][0]);
if(!redirect.contains(URLS.IP_ADDRESS)) {
options.path = redirect;
options.headers.clear();
}
return await fetch(options, requestStream, cancelFuture);
}
return response;
}
}
I disallowed following redirects.
Used the response object to check if it was redirected.
If it was 302, or 307, (HTTP Redirect Codes), I resent the request after clearing the Auth Headers.
I used an additioal check to send the headers only if the path contained my specific domain URL (or IP Address in this example).
All of the above, using a CustomHttpAdapter in Dio. Can also be used for images, by changing the ResponseType to bytes.
Let me know if this helps you!
I was using django restframework. I applied Token authentication in REST API. I use to pass token in request header (used ModHeader extension of Browser which automatically put Token in Authorization of request header) of django API till here every thing was fine.
But while making a click on Images/Files (which now shows the s3 URL). The Authorization automatically get passed. Thus the issue.
Link look similar to this.
https://.s3.amazonaws.com/media//small_image.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXXXXXXXXXXXXXXXXXX%2F20210317%2Fap-south-XXXXXXXXFaws4_request&X-Amz-Date=XXXXXXXXXXXXXXX&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
I lock the ModHeader extension to pass Authorization Token only while making rest to REST API and not while making resquest to S3 resources. i.e. do not pass any other Authorization while making request to S3 resource.
It's a silly mistake. But in case it helps.
Flutter: if you experience this with the http dart package, then upgrade to Flutter v2.10!
Related bugs in dart issue tracker:
https://github.com/dart-lang/sdk/issues/47246
https://github.com/dart-lang/sdk/issues/45410
--> these has been fixed in dart 2.16, which has been shipped with Flutter v2.10!
https://medium.com/dartlang/dart-2-16-improved-tooling-and-platform-handling-dd87abd6bad1
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[] { "*" });
}