I have a NodeJS application, from where I'm supposed to use web service (that support only soap) through soap calls.
The biggest problem is, that the Web Service doesn't have a WSDL api description anywhere. So my question is, how could I call servoce methods with NodeJS, use Soap without WSDL.
I have seen some solutions like use of require module.Installed the same(npm i require).Able to set headers and other options but dont know how to call the methods.
Thanks for any help.
How do you know a method to call and types and a number of parameters and return value without WSDL?
SOAP is a self-descriptive protocol that's why you can (and you should) use WSDL to get the whole description of what a certain service provides to you. All SOAP services normally have a rule that you can add '?wsdl' (or something similar) at the end of a service url to get WSDL.
You can try to construct a HTTP request by hand but it's worthless cause you will spend a lot of time to implement all method calls and to take into account types of parameters, their restrictions and structure and so on.
Related
I want to create an API at www.MyDomain.com that is accessible from public websites www.Customer1.com and www.Customer2.com. These public websites display each customers inventory and do not have any login features. They will use AJAX calls to read data from my API.
How can I secure the API so that it can be accessed via AJAX from different domains but no one can access the API to be able to scrape all of my customers data and all of their inventory?
I have tried thinking of different solutions on my own but they would all either require people to login to the public websites (which isn't an option) or it would require some secret "key" to be displayed publicly in the browser source code which could then be easily stolen.
Any ideas would be greatly appreciated.
Thanks!
P.S. Are their any obstacles that I am going to run into using Javascript & CORS that I need to look into now?
Anything that is accessible without authentication from a browser is by definition insecure, so you can't stop that. Your best bet is to have to have a relationship with the owner of customer1.com and customer2.com - the server apps for those two websites would make an HTTP call to you and authenticate with your service. Going this way also avoids the CORS issues you're talking about.
If you've already designed the client functionality, you can still probably do it without much change to the javascript - have it point to customer1.com for its AJAX call instead of your API, and customer1.com would accept this request and just act as a proxy to your API. Aside from the authentication, the rest of the request and response could just be pass-throughs to your API.
You can use Microsoft.AspNet.WebApi.Cors.
It's just need add ONE line at webapi config to use CORS in ASP.NET WEB API:
config.EnableCors("*","*","*");
View this for detail.
The simplest way to provide a minimum security here is to provide some kind of token system. Each app has its own token, or combination of tokens which it must pass to the server to be verified. How you generate this tokens is up to you and other than being linked to app's access, doesn't have to mean anything.
Provide a way for each API implementer to open an account with you. This way you will know who is accessing what and in some cases you can block/stop service.
For instance, a token can just be an MD5 hash:
7f138a09169b250e9dcb378140907378
In the database, this hash is linked to their account. On each request, they send this token with what they want. It is verified first to be valid, then the request is fore filled. If the token is invalid, then you can decide how to deal with it. Either don't return anything or return an "access denied" (or anything you want).
One thing to avoid is having a single token for everyone, though this can be a starting point. The reason for this is if some unauthorized app gets a hold of this token and exploits it, you have to change the token for everyone, not just the app that somehow leaked the token. You also can't control if someone has access to something or not.
Since you listed ASP.NET, I can also point you to WCF, which is fairly complex but has all the tools that you need to setup a comprehensive web service to service both you and your clients.
I hope this gives you a starting point!
EDIT:
There are security concerns here in the case that someone leaks their token key somehow. Make sure that you setup a way in which the app/your service do not expose the the token in anyway. Also have a flexible way of blocking a token, both by your clients in you, if it so happens that a token is exploited.
What is the best way to add authentication / security while calling Web service from javascript ?
I want my web services should only get called from my application , anyone else should not be able to access my web service by copying web service URL into browser.
From the first few answers it seems like its next to impossible.
So what should I reply to my client as he is unaware of word impossible ?
~Ajinkya.
Have a look at using the synchroniser token pattern so that the service can only be consumed with a piece of data known to the page which loads the service reference. There's an example of doing this with a web service in OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery (CSRF). This should achieve what you're after.
This is not possible. If you allow a client to access your webservice from JavaScript, the client will always be able to do that. You can only reduce access by using some kind of constraint, like a Token that needs to be sent along with the request to authenticate it. You might even turn it into a one-time token. But this will create new problems (e.g. what happens if the answer gets lost. The client javascript cannot rerun the query).
i need to consume a web api, which is located here
http://46.253.202.174:8080/ws-api/v1/rest/zdata/codesByJurAndUsage?jur=Boston,%20MA&usg=barber
I don't have any details of how it is implemented or access to the code of the API, I'm just trying to consuming the API, I can see the JSON return data if i type the url in the browser, but when i'm trying to call the API using $.getJSON, it gave me an access denied error. I understand that its a cross domain issue. I also tried a few other things, like jsonp data type, with no success. My question is, if i am able to see the results in a browser, shouldn't i be able to get the results from the scripts, or its no necessarily true?
Secondly, is there any other way, if the things i have tried so far was not successful.
thanks
You are correct, you won't be able to load this data via $.getJSON due to the Same Origin Policy restrictions. You'll need to load it via JSONP, or, if the service doesn't support JSONP (which it looks like it doesn't), via a proxy. A couple of options:
You can set up a proxy on your own server via PHP or another server-side language. This will allow you to request the data from your own server, getting around the same-origin restriction. You might look at a project like Simple PHP Proxy for this purpose.
You can use YQL as a proxy - this sends the data through Yahoo!'s servers and then you can load it via JSONP. Applying this technique with jQuery is discussed in this article.
I'm building an API and want Ajax to be able to interact with it. The API needs to allow inserting, updating, and deletion of data. Is it a good idea to allow any of these operations via GET?
For example: http://api.domain.com/insert_person/?name=joe
My original plan way to use GET for my "getting" methods (basically, just a simple DB query) and POST for add, edit, and delete. Problem is JS same-origin policy which would make it hard for Ajax to interact with my API. There is a jQuery workaround for GET (via JSONP).
Suggestions?
In a word: NO
GET should always be used only for retrieving information and should never have side effects, ever.
This is a best practice across just about every web api out there and has to do with both the intent of the verb as well as how existing software expects things to behave.
If you're trying to get around the same origin policy, GET via JSONP is the only possible front-end solution. If you've got control of the back end you can setup a proxy service that is on the same domain as the page, but relays to and from the API service.
If you're going to go down the JSONP GET path, make sure you read up on XSS and CSRF.
Add another layer of to handle your code and interact with your database (different domain).
You would still use POST and you can make a request to your db in the server side, using what ever language your are working with, example php will use curl.(to make request to a different domain)
If you allow to interact with your db using get, then anyone can simply type the url with the commands they want, so yes avoid it .
As others have pointed out, GET should not be used for actions with side effects like inserting, updating and deleting.
To allow cross-origin use of your API, look into Cross-Origin Resource Sharing, although it's currently only partially supported by browsers.
As the title suggests, I'm trying to figure out how to call a soap service using JavaScript. The SOAP Service is being run on Tomcat on my local machine. Along with accessing the SOAP service, I can also download/access/read the WSDL very easily.
I've been hitting my head against the wall for days now with this problem. While researching, I'm come across short examples, but none are comprehensive and detail how to accomplish this from start to end. That, or I've found a solution but it only works for IE or Mozilla.
Any ideas how to call a SOAP web service using Javascript (on major browsers)? Thanks!
(PS: I'm also using jquery. So if you want to accomplish this using some slick jquery tool, please feel free to suggest it)
SOAP is just XML so it should be possible to do this, however I'm not aware of any existing SOAP Clients written in JS
A more common method would probably be:
JavaScript initiates an XHR object which calls to a server-side AJAX helper using either GET/POST parameters, or a JSON encoded object
AJAX helper makes the call to either a Database or Web Service, as appropriate, and outputs required data object(s) as either JSON or XML
JavaScript parses response body (JSON or XML) and takes required action using specified data.
This has a couple of advantages over trying to call WebServices directly from JavaScript:
SOAP XML can be quite complex, which means more data to transfer to and from the client, which may be a slow connection. JSON in particular, but also an XML schema that just has the required data would be a much more economical on data usage
If the WebService requires any kind of authentication the authentication details will be exposed to all visitors.
Web Services are generally used for to standardise communications between separate systems, rather than for communication between the front and back end components of the same Application/Site.