how do I send Twitter updates in C# but without the need of OAuth?
The reason is, is because I heard that Twitter limits how many Tweets one can send, and I am planning to send a lot.
The officially supported means of sending a tweet via a third party application is by using the REST API twitter provides. This does require clients to use OAuth to authenticate.
If you don't want to deal with the API directly you might consider using a library which wraps the official API. I can't personally recommend any particular library as I have not used a Twitter library in a long while, however Twitter does provide a list of API implementations which may interest you.
It is possible that one could use the WebBrowser control to interface with twitter by website form fields with values passed to your application through your application's user interface.
Doing this is not advised for the following reasons:
It's officially unsupported and against Twitter's terms of use. This method depends on your application parsing the twitter user interface in order to find and populate form feilds. The names of these feilds may change at any tine without notice.
It will not circumvent the rate limiting. Twitter's rate limiting is enforced at the server side and the web interface is not likely to be immune to this rate limiting.
Related
I suspect that one of the c# method is never called (because of if codintions); but the software is a client and it's distributed to 1000 users.
So I would like to call some remote API to log every time the method is accessed.
This kind of tracking has got a name? Is it possible to use Google Analytics through c# as a workaround?
It's pretty easy to achieve using Google Analytics.
Is there any way to post events to Google Analytics via server-side API?
A c# wrapper has already been provided:
https://gist.github.com/0liver/11229128
I have a C# Azure Web API backend where data is retrieved from a front-end Ionic Mobile App (which is basically an Angular App)
The authorization of users is done via Ionic's cloud service, so they handle the heavy lifting of registering users via FB, Twitter, basic (username/password).
My question is, when I go to call services from my backend API, how can I make sure someone just doesn't read a hardcoded username/password inside of the internal javascript code to access the backend data?
I know it's pretty far fetched, but is there anyway for the API to know the request is actually coming from the app (Android and iOS) and not just from someone trying to insert data and comments from a web browser that is unauthorized?
Since you're calling the API from JavaScript that is available for end users, you can assume that your JavaScript and all the logic/credentials contained within are accessible to all.
There are fairly secure ways around this, and FB/Twitter and their ilk have implemented it (using OAuth). Essentially, on passing credentials to the API, a token is generated, which is then used for subsequent calls to the API instead of the credentials.
You can avoid people randomly firing off 'unauthorized' requests using nonces which are generated when you render the form, and can be used only once to submit the form in question. You can then time-limit the validity of the nonce on the API end. Unfortunately, it's not foolproof, but this will limit the damage of any sort of 'brute-force' attack that you might get.
Again, with any shared 'secret' (that would guarantee the origin of requests), you have to assume that anyone with enough willpower will be able to extract it from apps, thus any method you implement here will be 100% foolproof. Probably the best you can do is have a shared secret generated for each user on each device.
Short answer: you can't.
Long answer: you can (and must) validate the behaviour of a client but not the client itself.
For example we can take a look on Pokemon Go: after a few hours there were bots able to play, after a couple of weeks Niantic started assuming Machine Learning software engineer and encrypt its API using unknown6 algorithm for stopping the bots, but after a few days of hard working the bots came again online.
You can use all the secure method of this universe (whit an high expense) but if someone (that have good knowledge of software engineering) want emulate your client at the end I will reach his objective
I am creating an ASP.NET MVC website that uses a 3rd party API (web service) as a data source. It is read-only, and to date has been accessed by individuals using desktop applications (most in C#). I would like to consume this API using a web site in order to centralize information and give users historical information, automate certain repetitive tasks, and more easily allow sharing of information among users.
The desktop clients today experience throttling, and if you make repeated requests to the API using a client your IP will be throttled and/or banned. I think that if I made the requests to the API from my website, its IP would be banned the moment it saw any significant use.
Let's assume that I cannot work something out with the API owners. Probably the easiest way to work-around this problem is to do all of the API access using AJAX. When the user visits the website, he makes the requests to the API using AJAX then turns around and posts them to my website. I don't like this idea for multiple reasons-- first, it'll be slow, and second, I could not guarantee that the data sent to my website was genuine. A malicious user could, for whatever reason, send me bad information.
So I thought a better idea would be to establish a man-in-the-middle. The user would still be forced to make the AJAX request, but they would make it to a proxy or something else that I control, which would then forward it on to the real API and intercept the response so I could be a little more certain that the data I retrieved was genuine.
Is it possible to create such a "proxy"? What would it entail? I would like to do it using a .NET technology but I'm open to any and all ideas.
EDIT: It seems I caused confusion by using the word "proxy." I don't want a proxy, what I want is a pass-through that allows me to intercept the response from the API. I could have the client make the request and then subsequently upload it, but I don't want to trust client, I want to trust the API.
Let me explain this in shorter form. There is a client on a user's machine which can make a request to an API to get current information. I would like to create a website that does the same thing, but I am considering the possibility that the API web service may notice that while previously it was receiving ten requests for ten users from ten different IPs, it is now receiving ten requests for ten users from one IP and block that IP seeing it as a bot even though every request was kicked off by a user request just as it had previously. The easiest way to workaround this is to have the user make the request and then upload the response to me, but if I do that I am forced to blindly accept data from a client which is a huge no-no for any website in any situation. If instead I can place something that forwards the request along to the API preserving the IP of the user but is also capable of intercepting the response thereby proving that the data is authoritative, that would be preferred. However, I can't think of a software mechanism to do this-- it seems like it would need to be done at a different layer.
As for legal concerns, this is a widely used API with many applications and users (and there are other websites I have found using the API), but I was unable to find any legal information like terms of service beyond forum postings in the API's tech support section amounting to "don't make repeated requests, obey our caching instructions" etc. I can't find anything that would indicate this is an illegal or incorrect use of the web service.
You could implement your proxy. It wouldn't need to be AJAX though, it could just be a normal web page request that displayed the API results if you wanted.
Either way, in .Net you could do it using ASP.Net MVC. If you wanted AJAX, use a Web API controller action that implements the source API, if you want a web page, just use a regular MVC controller/action.
Inside your controller, you would just make a web request to the source, passing through the parameters.
In order to avoid throttling, you could cache the results of each request you make from your server (using the normal ASP.Net cache), so that if another client attempted to make the same request, or a similar one maybe, you could return the cached results instead of making another request to the API.
You would have to determine how long the results should be cached for, depending on how up to date the data needs to be in your client. E.g. For weather data, caching for an hour would seem OK. For more fast moving data it would have to be less. You have to strike a balance between avoiding throttling and keeping data fresh.
You could also intelligently fetch more data than you need at each request and then filter the result set that you return to your client. This could give you a better cache hit rate.
Iam writing a Phone App where the end user should be able to access their own personal messages and other personal content.
Does anyone have some good ideas of how to create a service like this, should i use Soap or Rest, should i simply send the username/password with every request or ?
What would be the best choice for a service i would like to access from all three platforms and that only returns information specific to the authenticate user.
As a suggested alternative to WCF that's at least worth taking a look at, ServiceStack, an open source REST Web Services Framework, is well suited for use in a mobile app and it supports the Mono platforms. It also has built-in support for user authentication. At the very least, it offers a JSON serializer that performs very well.
There's a Wiki for ServiceStack here.
I don't know what the support is like for MonoTouch / MonoDroid, but WCF supports secure services without adding username/password to every request manually (it actually does, but it includes it in the headers).
See this blog post for a great starting point for using WPF Custom Username/Password Validator: http://blogs.msdn.com/b/pedram/archive/2007/10/05/wcf-authentication-custom-username-and-password-validator.aspx
I'd like to write a console program in C# that posts a Tweet to Twitter. I've never used the Twitter APIs before and don't know anything about how their authentication works. I found an API library called Twitterizer, but it seems geared towards web applications and wants the user to logon with a web browser. All the API docs on Twitter's website seems geared around this scenario as well.
Is it possible to access the Twitter APIs using a console app with no web browser access? I'm perfectly fine hard coding in the name and password for the Twitter user I want to post under as well. Thanks!
Mike
You'll need to use OAuth for authenticating in twitter.
Then use regular HTTP Request to use the twitter JSON-based API.
Here you can find a good article about OAuth, Twitter and console applications.
Also take a loot at linq2twitter lib. From it's documentation;
The Twitter API is built using
Representable State Transfer (REST).
Wikipaedia defines REST as "...a style
of software architecture for
distributed hypermedia systems...",
but I'm going to be so bold as to try
to simplify what that means. In
practice, REST is a Web service
protocol built upon Hypertext Transfer
Protocol (HTTP). You use the REST Web
service by making an HTTP call with a
URL and getting text back in some
form, which is often XML or JSON. So,
if you were to write code that made an
HTTP request with the following URL:
http://api.twitter.com/1/statuses/public_timeline.xml
You would get back an XML document
with all of the Twitter statuses from
the public timeline, which is a
snapshot in time of the last 20 tweets
at the time of your request. Go ahead
and open your browser, copy and paste
the URL above into the address bar,
and see what you get back.
I couldn't find any decent information on the web on how to do this, so I decided to write my own blog post with all the details.. Enjoy!
http://blog.kitchenpc.com/2011/01/22/rise-of-the-twitterbot/
of course you can use anything to connect to Twitter via RESTful api.
you should use oauth, and set up your application in http://dev.twitter.com, then you should read all articles listed in documents, you must specify your app as Client but not Browser so user input a number to get through authentication.
you can use many libraries so that you can save your time, all are listed in the documents
and be CAREFUL, you should not use Twitter's own api console which is buggy (as i know parameters somtimes can't be parsed), you should use APIgee instead which is powerful and stable.
if you want use basic authentication, you should use api proxy (one famous is twip), if you just need only one single C# apps, you must code by yourself:
you should use given username and password to login twitter, parse cookies passed
use normal oauth to get temporaly access token url.
use cookies got from step 1, emulates form submit to allow your apps, capture PIN code
use pin code to finish oauth.
MOST IMPORTANT, you must store access token in client's machine so next time you can bypass above steps
Just wrote a Twitter Bot in C#. This is currently posting tweets to #valuetraderteam.
https://gist.github.com/sdesalas/c82b92200816ecc83af1
The API component in the GIST below is less than 500 lines, only dependency is Json.NET, you'll need to download the latest DLL for either x64 or x86 (depending on what platform you are targetting) and include as a reference in your project.
There is an example at the bottom of the page of how you can make a tweet from a console application
Hopefully this is useful to some other people out there.