I am currently using Django 1.2. I am trying to send an ajax request to my Django site from our newly established drupal installation. I am able to send the request no problem from one view to another on my DJANGO site but I am unable to send a request from my local machine. I continue to get an error, I assume there is a CSRF verification issue. Does anyone know how I may resolve this issue.
-Greg
Not so recommended but quickest:
You can easily disable csrf protection for certain django views using csrf_exempt decorator. You can find more info in django docs
this might be also more justified if you run your app in 'trusted environment'.
Please mind that this causes some security problems. If you decide to use csrf_exempt you can think of some additional verifications (eg. you can allow requests on some view for some limited set of IPs or something else).
Related
I have been trying this for quite some time and with no avail. Would someone point me to the right direction.
I have a simple suitelet
the suitelet dumps a html in the response by reading a file
The html has a button. On ajax call of that button, a restlet gets called and a request is sent.
This is working great with Login and internal calls. However, I want the suitelet to be available without login and also the restlet.
When I do that, I get CORS error and using jsonp when I relsolve that, I get 401 Unauthorized
Tried Outh and NLAuth, no avail.
Will really appreciate any help or pointers.
If the info isn't sensitive you can call the suitelet from the domain of your website. If you have enabled https on the site then that'll just work
e.g. https://forms.na3.netsuite.com/app/site... becomes http://example.com/app/site...
If you are using SCA then you can also just do this by calling a .ss service function. The nice thing about that is that you can set the role on the .ss file and have better control of your resources without just making the customer center role capable of seeing everything. Same issue with https though.
If the info is sensitive you can get around the issue on most browsers by embedding an iframe at the https:// forms etc and using the onMessage operation to transfer info from the non-secure to the secure. (see https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage)
It's certainly possible to call a RESTlet from a Suitelet but it sounds like your issue is more how to call the Suitelet securely.
I want to call REST-services from my Angular-app. However, these REST-services are hosted on WLP and are part of a WAR-file developed by some company a while ago, ie. we have no source code.
I can call GET-methods without any issues from Postman, I just need to set authentication and accept headers. However, calling these GET-methods from Angular via web browsers will trigger preflight request (OPTIONS) without Authentication header prop. Seems to me that OPTIONS requests are triggered by the browsers and Angular cannot set headers for them. I confirmed OPTIONS requests need authentication by running requests via Postman with and without auth header prop.
Similar problems were discussed in other posts on stackoverflow but in such cases people had control over their server side code and could alter it to avoid authentication headers for OPTIONS request. Clearly in my case, I cannot do it.
My question is if there is a possibility to configure WLP to not ask for authentication header prop in case of OPTIONS-requests (seems to be configurable for Apache web servers and Tomcat)?
Kind regards
A.H.
Even without source, you should be able to edit web.xml and modify the security-constraints to punch a hole for OPTIONS.
I am trying to hit USPS address validation API by AJAX call and I am getting 'Cross-Origin Request Blocked' error.
However when I am trying to access the same address though URL, I am getting the results.
Has this error something to do with approval thing?
The id I am using for this has been approved and I am able to get the result by the API through URL.
I want to access it though scripting. Please help.
Any help would be appreciated.
Thanks in advance.
I think the way you might want to do this is to have the Ajax requests go to your web server -- the same HTTP server where the page came from. And then your server-side program (in PHP, or Python or whatever you're using) relays the request to the USPS server.
Making the request browser-side, from Ajax directly to the USPS server, is just the kind of suspicious activity (called Cross-Site Scripting) that browsers are learning to block.
CORS could theoretically be one way to unblock a Cross-Origin Request, but in that scheme it would be the USPS API server that ultimately grants that permission for pages from your domain. Tech detail: by inserting an Access-Control-Allow-Origin header in response to a request with an Origin header in the Ajax back-and-forth.
I have an ASP.NET MVC4 sub web application added in to an existing ASP.NET WebForm web site. the whole website is using forms authentication.
In my MVC4 client side, I use Backbone.js for building the application, and the client application is most likely a SPA.
Everything works fine, but after session timeout my application does not redirect to log-in page.
I tried the error callback on Collection.fetch method, it was triggered (which is good) when trying to fetch after session time out.
However, the response status code is 200 (OK) with response content is the log-in page content.
So, my question is, in error handler how do I know whether the callback is triggered by session timeout or any other unexpected error?
If determined, how should I do to let Backbone redirect page to log-in page while referring current page?
Here is something what Phil Haack had blogged about
Exceprts from the post :
Possible Solutions
I’m going to cover a few possible solutions I’ve seen around the web and then present the one that I prefer. It’s not that these other solutions are wrong, but they are only correct in some cases.
Remove Forms Authentication
If you don’t need FormsAuth, one simple solution is to remove the forms authentication module as this post suggests. This is a great solution if you’re sole purpose is to use ASP.NET to host a Web API service and you don’t need forms authentication. But it’s not a great solution if your app is both a web application and a web service.
Register an HttpModule to convert Redirects to 401
This blog post suggests registering an HTTP Module that converts any 302 request to a 401. There are two problems with this approach. The first is that it breaks the case where the redirect is legitimate and not the result of FormsAuth. The second is that it requires manual configuration of an HttpModule.
Install-Package MembershipService.Mvc
My colleague, Steve Sanderson, has an even better approach with his MembershipService.Mvc and MembershipService.WebForms NuGet packages. These packages expose ASP.NET Membership as a service that you can call from multiple devices.
Some more info from comment of this blog
We had the same problem. But what we did, was to hook to AuthenticateRequest (just like you did) and we also checked the request to see if it's ajax or not (again, just like what you did). But at this point, we simply returned a JSON like {location: 'http://www.domain.com/path-to-login-page'} and we simply ended response in that method with HTTP code 200. This way, jQuery still gets a JSON result. But if the result has a "location" property, we simply do a client-side redirect to login page. That's our way and it works like a charm.
Im using jQuery validate plugin and every form has multiple validation levels.
level is by validate plugin
level is:
data is submitted to site
I get a reply
if everything is ok -> JS redirects to url
if there is an error, it shows warnings
Now I wonder, is it safe to send login info via ajax? I know that with addons like firebug, I am also able to get all POST parameters with normal submit. But can somebody else interfere with ajax login request and steal precious data?
is it safe to send login info via ajax
You do use HTTPS, do you? If you do it's as safe as form submit.
Are you issuing requests over HTTPS?
If you mean someone else on the network, then see the earlier comments about HTTPs.
If you mean "can someone inject something into a page and steal the data", the answer is yes. As you've observed, the user can install plugins which could do this; it's also possible that your page could be inadvertently be the target of injection via cross-site scripting or some other flaw.