I am a newbie in WebServices. I wonder if all WSDLs are public? Aren't there any WSDLs that are kept after a login process like in OWASP's WebGoat project?
Thanks in advance.
WSDL is the contract definition for your web service. It is used to generate a proxy for your client so it can interface with the service. If you want a "private" web service, you will still need the WSDL to create your proxy classes during development, but then you can disable the ability to access the WSDL so that it cannot be used from your production web service.
Related
We created a webapp (all code is on EC2 server) and now, we are trying to create an iOS app using Monaca, which is based on OnsenUI/Cordova.
We would like to use Monaca for the "front-end" and leave EC2 as the "back-end". What would be the best way going about this? Apologize for the loose language, we're novices. Any guidance, suggestions, and etc. are GREATLY APPRECIATED.
You would need to create and expose a webservice endpoint with methods that handle your requests. In my apps I create a WCF service using C# in Visual Studio then I call the exposed methods using jQuery ajax or JavaScript's XMLHttpRequest(). You also need to allow CORS on the server.
I have a WSDL service which worked fine (and is still working in .net 4.x) and fairly newcomer to .NET Core 2.0.
I created the WSDL web service reference (The same steps followed as https://learn.microsoft.com/en-us/dotnet/core/additional-tools/wcf-web-service-reference-guide)
My question is how to consume this service? Do someone know of a good tutorial? Any help would be greatly appreciated.
Thank you in advance
My question is how to consume this service?
The WCF Web Service Reference Provider Tool creates everything you need.
The client is automatically created with all the end-points in the service and any associated classes such as service parameters.
During the WCF Web Service Reference Provider Tool wizard you specify a namespace for the client, so if you entered CompanyName.Service you'd be able to create the client by typing var client = new CompanyName.Service.ClientName();
Please note that the name ClientName will be generated by the tool, and intelli-sense will you give you the actual name.
Once you have the client you can call any method on the service in the normal way. Such as:
var response = client.CancelPolicyAsync(cancelRequest);
Please check the link here:
Calling a SOAP service in .net Core
Calling a SOAP service in .net Core
How to Call WCF Services and Create SOAP Services with ASP.NET Core
Click here!
Your WCF service still is on .NET Classic - so nothing changed - you should consume it as always you do as regular WCF service.
What you have done creating WSDL web service reference - you have created client for Standard framework. Put it into separate Standard project. Then it can be referenced in core and classic frameworks aps.
I have a standard nteir setup :-
Web server -> App server -> DB server
I have an MVC 5 web application sitting on the web server with controllers calling a WCF services project sitting on the App server. WCF services project uses EF6 to marshal data on the DB server.
I am wondering if WCF is overkill? Is there is an easier way to achieve this same architecture? I am thinking I should have gone with Web API on the app server and then just call the web API from the controllers with the HTTPClient?
Or, I could even just use a plain MVC project on the App server returning JSONResults to the MVC controller on the web server?
It depends...
You have to understand what are the benefits of each set up. This is not exhaustive, just a quick brain dump. This should give you some hints to look further as in the wild world there might be many more reasons for choosing one or another solution.
Why WCF. Are you going to have different clients to your backend ? You need some entreprisy security between clients and you backend ? With WCF you could configure Http, TCP endpoints, set message or transport security and a lot more. It could be needed for example if your doing an intranet application and you would like not only to have your UI (MVC application) but other systems going to it. If this is not needed WCF seems overkill here.
Web Api is also agreat choice if you would like to built more REST oriented api, enabling content-negotiation for different clients (different media-types). Building REST is not about issuing JSON, it's much more and this would be too long to explain it here. If your client is not only your MVC app, but you could have a need for a api for other mobile devices, OAuth authentication and the so, this could be a good way to do.
Plain MVC app would also fit if you don't have any special needs, go for it. No overhead needed. Keep It Simple And Stupid.
I hope this helps
I would not change this.
WCF is a good choice for communication between Web Tier and App Tier. I would never put my App Tier exposed to outside world, so if there is any communication to my app from outside world, it would be through Web tier only and if there is a need to support multiple clients, I would create a WebAPI on web tier and expose that.
I would keep App tier only available to Organization internal and with WCF I would have flexibility to write service code and contracts which can then be exposed over various bindings (transport, security, etc.).If you are building a service in your organization and plan to support multiple protocols, or simply use protocols other than HTTP (tcp, name pipes, udp, etc.) then WCF is indeed a good choice.
My web database server is being moved from the DMZ to the company LAN (don't ask why!). The downside of this is that my MVC 4 website is now gonna have to talk to an app server with web services (or web api) to get to the database. This isn't a major headache for most of my stuff, but I'm using the SimpleMembershipProvider for user authentication and that seems to need direct access to the database.
Is there any way to get SimpleMembership to talk to a web service or do I have to use a custom membership provider instead ?
I'm faced with the same situation, and while I haven't written or tested the code yet, I'll be writing a class to inherit from SimpleMembershipProvider and overriding the methods to call methods from the service (web api).
Is this the approach you ended up using?
I want to build my web services serving JSON data utilizing RESTful architecture.
But I want my own client apps only that can request from my web services.
Basically, my web services contain sensitive data that is not for public consumption, but I wanted to build it that way so I can build many different client apps that connects to my web service.
Would appreciate any ideas for this, thanks.
The fact that it's RESTful or uses JSON isn't a relevant factor when it comes to securing a web service. Any web service would need to be secured in the same manner. There are a few things you should do:
If possible, don't host your web service on the Internet. If the web service is hosted within your company's LAN, for example, it won't be exposed to public consumption unless you specifically exposed it through your router.
Set up authentication and authorization rules. If you're hosting your web service inside of a Windows domain, you could simply use Windows authentication and set up rules based on Active Directory users and groups. Other options are to use HTTP authentication, client certificate authentication, or if you're developing in .NET, forms authentication.
Use encryption (HTTPS), especially if your web site is hosted on the Internet.
You just need a couple things in place to do this. First, the service client will need to authenticate against your service (over HTTPS) to make a request. Once the client is authenticated, you can return a private token which the client has to include with this token. As long as the token expires after a reasonable amount of time, and a secure algorithm is used to generate it, this should do what you want.
If you have more strict security requirements, you can follow Jakob's suggestion, or have the client start a VPN session prior to making requests.