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
:)
Related
I am new to SAML2 with PING I can't able to find any documents how to implement this one. Is there any step by step documents or examples to implement SAML with C# .Net.
I want to create metadata first. Is there any example how to create metadata for SAML.
If you're wanting to act as a service provider and be VERY .Net-centric, then you should either pick a SAML stack like this one, or, better yet, just go with a commercial SAML stack like ComponentSpace.
Of course, if you are really going to be Ping-specific there is always the .Net Integration Kit that you can review.
I always encourage adoption of Open Source solutions like Shibboleth, however, as it's pure SAML middleware and largely agnostic re: what technologies your application uses. So long as you can read server variables or request headers Shibboleth has everything you need to act as an SP.
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.
I am new to RESTful web services. We are taking the REST route for building our public web services to be consumed by out clients.And i had a few questions.
Are there any kind of limitation with pure REST webs services? and if yes then would a hybrid REST web service take care of those limitations?
I am thinking about using SSL + Hash Message Authentication Code (HMAC) in Authorization header for security along with IP based based filtering. what do you guys think about it?
Are there any good client side tools for testing?
Currently i am using the following
http://code.google.com/p/rest-client/
And what about some kind of client side code generation tool?
The following links are my source of info.
http://msdn.microsoft.com/en-us/library/dd203052.aspx
Link
The first thing to keep in mind is that a REST service should be stateless, which is very different when compared to a SOAP/RPC type of service interface. Using REST methodology requires you to rethink how you want your clients to interact with the service, breaking down the interactions into clear and concise method calls.
REST
+ Lightweight messages, very little overhead (other than the XML itself)
+ Easily readable results, can easily test with a web browser
+ Easy to implement
- Looser interface, loose type checking
SOAP
+ More rigid, with a strict contract definition
+ Plenty of development tools available.
Looking through the WCF MSDN documentation, WCF SOAP support was integrated from the start while REST support is a recently added feature. I myself am having a hard time finding documentation for authentication/security for REST services, as most of the documentation is directed towards SOAP.
Client side generation tools: I haven't come across any for REST services as REST doesn't define a service contract as SOAP does. WADL is an attempt to do that for REST services.
http://en.wikipedia.org/wiki/Web_Application_Description_Language
http://wadl.codeplex.com/
I'm interesting in reading more responses dealing with authentication and security, as I'm looking into that myself.
This is a good starting point of a WCF REST WebService:
REST / SOAP endpoints for a WCF service
(BTW: Stackoverflow has nice REST kind of urls.)
You can test a REST service with just a web browser (Go to the url and get the XML or JSON). Fiddler is also good tool, and FireBug-plugin for FireFox. I usually make a thin service-interface project and a separate (unit-tested) logics-project.
For authentication I would first generate a Guid and a timestamp. Then based on those a hash (.NET supports SHA256 and SHA512). The Guid can be stored to server (database table) to map it some concrete numerical id. Then you can have a rest url like:
/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y
and just disable the hash & timestamp check in development environment (e.g. with AOP). With timestamp I would check that the stamp is between 15 minutes back and forward in time (=should be enough to prevent attacks).
Will your service be visible to the public/internet and is your client a jQuery or Silverlight -client? Then you still have a problem: You don't want to include a secret key in the client software code.
So you need to generate hash in server and some kind of cookie to store the client session. (This can be done e.g. with a separate login-page/application in a folder with different config-file.) I remember that this book did have something on the topic:
If you want to enable the HttpContext when using WCF, you need to set <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> under <system.serviceModel>.
Then you can check current user identity from HttpContext.Current.User.Identity.Name.
However, if you want to make a pure REST service then you don't use cookies, but a HTTP Basic Authentication coupled with SSL/TLS for each call.
I think that it's easy to make a client with just LINQ2Xml or jQuery so maybe client generation is not needed.
Or you can also have both, a SOAP and a REST interface, and use a service reference to make a client.
One thing to keep in mind is that you can take REST as a philosophy (everything should be reachable by a clean URL, without hidden strings attached) or as a dogma (you have to use PUT and DELETE even if that means a lot of hardship down the line).
The emphasis is on simplification - like using simple data types for params instead of stuctured pileups, nor clobering interface for superfluous reasons (like towing giant page "title" in a url), not using headers which are not well known and de-facto standard.
So, you can design perfectly RESTful interface using just GET and retain usability and testability from web browsers. You can also use any standard authentication methods or several of them for redundancy depending on your actual target audience. If you are making an app to run on a corpnet with standardized credentials and tokens you can continue using that. If you are doing something for very general access you can use combination of GET args and/or cookies - keeps your URL-s clean for 99.99% of users.
You can even serve both JSON and XML (like Google maps for example) and still be RESTfull, but you can't do full scale SOAP (complex input types etc). You can do limited SOAP - simple types for requests, always expressible as GET args, people still get WSDL for documentation.
Hope this paints flexible enough picture - the way of thinking above any strict dogma.
Is there any open source libraries for creating http based authentication like flickr and remember the milk?
http://openid.net/ is nice for public facing sites. Same sort of thing stackoverflow uses.
Otherwise it'll depend on your web development framework.
You'll be signing requests. Any OpenID or OAuth library will have code which does that - if not a separate library, something you can rip out, even though you're not using the protocol flow.
Alternately, there's demo code for Amazon AWS clients in their developer docs which also signs requests with API keys and timestamps. It's the same process on the client or server side - comparing a hash with the original - so you'll probably just have to translate their request model to whatever your framework uses.
Neither of these are exactly what you're asking for, but it's a start.