I have an application that runs on a server and uses SQL server 2005. If I wanted to make this application integratable with other systems such as a CRM, what would be the best strategy? My idea was to create a public Web Service with authentication...does this sound like the right approach?
Any idea's would be appreciated.
Yes, Ideally all integration is done using industry standard communication protocols, requiring some middleware that links these standards. Ideally these protocols would be something like a webservice as you say where the API ensures validation all data imported into your system.
Most basic integration between systems means Transfer of Data between systems. You can either choose to build an API to which you or others provide the middleware to connect. Or depending on the nature of the applications, you your case CRM, it may be worth ising this same API to build an Import/Export mechanism where users can just just Export their data into xml, CSV and also import their data, building a nice interace to map any CSV format to your own fields is a nice touch and means less technical users can perform non-automated tasks.
Related
Could somebody help me find an example of getting data from SalesForce using its api with c#? E.g. getting a Contact information by its email address?
There are ready-built libraries for .NET integration such as https://github.com/wadewegner/Force.com-Toolkit-for-NET, I'd suggest starting with one of these. (old but official). Another one could be https://github.com/anthonyreilly/NetCoreForce
Old, stable, battle-tested or you want to craft the SOAP / REST messages yourself, read up about security tokens, oauth scopes, error handling, bulk API options? I'd offload at least the login part to existing library but your call :) There are many ways to connect, there's even (paid) SQL server plugin or azure data factory solution...
".NET toolkit" seems to use old SOAP API. It's... simple. You provide username, password and you get total impersonation. The app will be able to do everything the connecting user can do. The other one seems to use client id and secret, this sounds like newer REST-based API implementation (OAuth2 keys). This is slightly better, you get extra security layer of the connected app and for example if "scope" is only set to Chatter - even admin's session connecting via this app can't be abused.
There are slight differences between the APIs and the way they handle certain features (for example downloading a Document/Attachment/File via SOAP API will give you base64-encoded payload while REST API will give you a link to download the binary separately). And of course how much of the API does the library actually implement, how well it's maintained...
But generally I'd say explore the libraries first. At least steal some ideas around login logic. If nothing off-the-shelf works for you - consume the WSDL and hand-craft something in SOAP API. Worst case - craft the XML messages manually, worry about escaping special characters etc.
Get an account and api key and then use the official programming interface:
https://developer.salesforce.com/docs/apis
i'd choose: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_resources.htm
So You have to read and understand this: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/using_resources_working_with_searches_and_queries.htm
:)
I need to push data from applications made in VB.net, Java, C#, C++, Node.js and other modern languages to our server. These applications are running in retail stores and our service is 3-party service. I am planning to offer REST API to push the data but my concern is how do I authenticate a single store.
One of the ways I thought was using the AWS way : AccessKey and Secret Key approach outlined here :
http://docs.aws.amazon.com/AmazonS3/latest/dev/S3_Authentication2.html
Each store can have multiple billing machines/computers --> so what will be a better approach to authenticate because the AWS way requires to paste the Keys from our interface to their local machine setups (At this point I am assuming our services will be directly called from the front end application rather than Back-End Servers.
I am confused how to go about approaching this problem - if the REST API Calls should be made from front-end or back-end services and if its front-end how do I go about authenticating the store.
To first answer
I am confused how to go about approaching this problem - if the REST
API Calls should be made from front-end or back-end services and if
its front-end how do I go about authenticating the store.
Since you say
I need to push data from applications made in VB.net, Java, C#, C++,
Node.js and other modern languages to our server.
To me it sounds like you want server (your customers) -> server (your REST API) communication.
Before getting into security options, you need to think about security-ness and time/resources.
Starting with security, if you're dealing with HIPAA, PII or other sensitive data, then definitely do more research.
Next, time/resources. A SaaS service like AuthRocket or Okta will make life much easier, however, it is a monthly expense. You can roll an open source library into your API, you'll just need to spend the time to develop, test and maintain (and deal with stuff like user registration, lost pws, etc).
And so now, authentication. ID/Token auth like Amazon is the most common way. Every REST request a customer issues will include their ID and token (eg ID=customer-123, Token=laksdjflaksjdf). To handle a customer w/multiple machines, you can issue n tokens, one for each machine. The customer would be responsible for putting the credentials on each machine. Again, this is the most common way to do things.
You can also use OAuth, but this doesn't make as much sense for your use case since its companies and not individuals (usually OAuth is for developer-oriented APIs).
There are also other various token based authentication approaches, but these are usually better suited for client->API requests (websites->APIs).
I am developing an .net Winforms application and I need to secure the connection to the sql server 2008 database. I plan to create a webservice as a middle tier that will handle the authentication and that will provide data manipulation. Is there a better way to go with? Does .net have components or tools for that? What is the best technique?
Any info would be appreciated, thanks.
Define "secure". Obviously you wish to restrict access to data to users who really need that data. However, more information about the architecture is needed; is this an in-house app that will only ever be used inside a (secured) LAN, VPN or hosted environment? Or is this an app used on computers you do not control, that will transmit data over the Internet? How much security you need depends on what types of users will be using the software, from where, and how sensitive the data is.
MSS has pretty good security built-in. You can tie SQL users to Windows domain accounts, you can restrict "securables" (tables, views, SPs, etc) in myriad ways based on user or role, etc etc. I would first look at those capabilities, and seriously consider taking advantage of them in your security plan. One SQL user defined for use by any user of a particular piece of software, which has the permissions to do anything the software may require, is simple, common, and highly insecure.
If that's not good enough, or you want to fully abstract your data layer (for instance, if you need the software to be able to be pointed at any DB type from MSS to Oracle to MySql), then it might be a good idea to implement a Repository model with a service proxy. Like Brian, I encourage you to have a look at WCF. A WCF service is highly configurable, and can provide for independent authentication and for encryption. A well-designed WCF service will be very secure indeed.
Behind the service, you can implement a Repository pattern, which abstracts the details of how data is retrieved from the data store and exposes simple methods that return objects containing the data you want in a ready-to-use form. Now, your service methods will just map 1:1 to Repository methods, possibly with some translation to DataContract-serializable objects instead of the richer domain model available on either side of the service.
Have you looked at building a service tier, using WCF? WCF can bring a whole new layer of abstraction and security from the actual physical database.
WCF also allows you to use more secure bindings than a traditional web service allows, with built-in logging.
Also, check out this book sometime if you want a really good read on .NET Security:
The .NET Developer's Guide to Windows Security by Keith Brown
There is a need to develop some "Service" program that will receive and process BLOB data from Oracle DB server. The clients will be written in Delphi 2010. I have freedom of choice that technologies I will use to produce server part of this project. And that's why I have posted this question here. Could you guys point me some blog posts, articles, forums where I can get various information about creating such type of services? I have an experience with Microsoft's WCF services, but it has bas intergration with Delphi clients via WSDL. Now I stopped on ASMX Web Service written in C# and need to get some samples how can I transfer BLOB data between server and client. It would be better if server and client communicating thru raw socket, instead of incapsulation all data in SOAP. Thanks in advance and strongly hope for you help, guys!
I would recommended you to use RemObjects SDK for develop server & client web services applications, it has many features not available on Delphi & .Net, also they support different messaging, so you can use binary message instead of SOAP to transfer the BLOB data, which is much faster and more compact.
They also .Net version of server and client so you can mix between them.
A nice and standard way of handling BLOB fields is the REST protocol.
Thanks to the REST protocol, you can GET, POST, PUT or DELETE a binary BLOB from its URI. That is, if your URI is dedicated to the BLOB field, you'll be able to use raw binary transmission, and no MTOM or Base64 transmission.
For instance, you can get a BLOB content with ID=123 with a GET at such an URI:
http://servername/service/123/blob
It will work also from a standard web browser. So if the BLOB is a picture, it should be displayed directly in the browser.
With a POST at the same URI, you add a new blob, or with a PUT you update the blob. With a DELETE verb... you delete it. This is what RESTful means over HTTP.
This is, for instance, how our mORMot framework works. It is also able to fast have direct access to the Oracle database on the server side, with some dedicated classes. What is nice with such an ORM-based framework, is that high-level clients can use objects, and handle much more than only BLOBs, and that it handles URL-level security and authentication.
But you can easily write your own service using some units available in mORMot, if you don't need the whole RESTful ORM feature:
For a fast http.sys based HTTP/1.1 server, take a look at SynCrtSock;
For the HTTP/1.1 client access, the same SynCrtSock unit defines some client classes;
For very fast direct access to Oracle, see SynOracle.
This is all Open-Source, working from Delphi 5 and later. There is a lot of documentation available (more than 600 pages), including high-level presentation of such concepts as REST, ORM or n-Tier.
This is fairly high-level, but so is the question:
If it is a "raw socket" it isn't really a "web service"; although there is of course the middle ground of REST or a HTTP POST.
If you are looking at a web-service, and the data is non-trivial, then you probably want to look at MTOM to avoid the base-64 overhead (which is supported in WSE 3, or (simpler) WCF via basicHttpBinding). I would expect most tools to have a reasonable comprehension of a basic web-service with MTOM.
if you want to expose some data in a data base (in this case blob data in oracle) as a web services WSO2 DSS[1] provides an easier solution. This is under Apache license and it is available for free. Since all the WSO2 Products are based on WSO2 carbon platform the services you create supports MTOM, WS-Security and other Web service related features as well.
[1] http://wso2.org/library/dss
I have an online application with PHP & MySQL. I need to provide some functionality using a a desktop application built in C#. My task includes follwoing..
Authentication
Database query
Please suggest me a proper way to proceed with this scenario.
Some of my doubts..
should I use webservice in my PHP end?
How to authenticate?
any security issue?
Yes. You will need to build a webservice on the PHP end, that contains a method that will execute your query. You can then add a 'Service Reference' in your C# application to the PHP service.
Regarding authentication: it depends on your scenario. If you are the only user of the webservice you can use basic authentication (over HTTPS) to ensure that your credentials are safe from sniffers.
Problem with security is that you will have to rely on tokens, keys, or something. And because these are stored on the desktop computer that uses the software, someone can steal these secrets (by using a decompiler f.e.). If security is really important, you will need to rely on 3rd party solutions like DigiPass.
Webservice: It is the standard way of working. But it has some overhead (XML and that all) so if you transmit complex structures you might need other options (passing data with your own codification over an HTTP connection, for example). Maybe even a mixed system were simple requests are through plain webservices and more complex ones go through HTTP but without using XML, or passing a structure codified this way inside the webservice. Anyway, try to keep non-standard solutions to a minimum.
Depends of your security requirements. Webservices is HTTP, so the standard web authentication works.
Same as before, you have the basic solution, it depends of what your application does.