I'm writing an HTML5/JavaScript application that needs to consume data from an existing WCF RIA Services Domain Service. Requests will always be cross-domain so I have added a JSONP endpoint onto the service using the solution I posted in this stackoverflow question.
Using jQuery.ajax() I can successfully retrieve data from the service when authentication is off. With authentication on I get this error:
Cross domain javascript callback is not supported in authenticated services.
This is by-design behaviour so I need a workaround!
The possible solution I'm looking at is to try and use OAuth. My current thinking is to use the JavaScript library and DotNetOpenAuth code referred to on oauth.net. I'm hoping to implement the service in a seperate server instance with OAuth authentication (instead of forms/windows) and tack on the relevant request headers to my jQuery calls.
So my reason for posting is, does this sound reasonable and is this the best approach? And if so does anyone have any experience, tips or samples they want to share? :)
Thanks,
Chris.
Related
I already Googled that, but I didn't found any answer that satisfy me, maybe because it's impossible.
I want to know if I can authenticate a website directly from JavaScript to a Symfony API rest. My goal is to create a script in JavaScript, which make ajax requests to the API (the API accepts cross origin requests) and get some data in the response, but the website(s) needs to authenticate with the API to get this data.
I can certainly use JSON web tokens or OAuth to make the website authenticate as a user, but in this case I need to have some script on the server side of the website and call it from ajax to get the website authenticate and return the token in the response. I don't want to store anything on the website, only put my script tag in the html, to facilitate the installation of the service(it's a widget) for webmasters.
I also know that I can do that with referrer authentication, but I will avoid that, everyone can change referrer in the request headers. I can also put an apikey in the link of the script <script src="mydomain.com/myjs.js?apikey=MY_API_KEY"> but everyone can access the apikey and use it from everywhere.
Is there a way to do that safely?
After some research I think the only solution is what I already done, apikey-referrer authentication:
How to keep API keys secret when using client side Javascript?
How does Google Maps secure their API Key? How to make something similar?
I've worked a bit with Twitter web API, I know it works with OAuth, I've consumed the API using a python library. I've also tried a bit of Instagram API using a Java Script small library.
I know those perform web REST requests in the background, authenticating first and then querying requests as I code.
However, what if I want to perform the requets using jQuery $.ajax from a web application?
I've read some docs and sites and it seems it's just possible. Like only ajaxing to the API routes, starting with the authentication route.
But, how does this process work? I mean, I query by AJAX to the auth route and then how do I keep track of that authentication. How to keep that communication? Will the redirect URL play its role then?
Reading this site for Instagram API I start getting a clue about it, but got the doubts mentioned above.
I want to perform all AJAX requests in the Java Script server background (I'm using node.js), assuming I will provide my apps OAuth in the $.ajax. Is that OK or I can actually code it on client site keeping my OAuth tokens save?
And, if it's concern of this same question, when it comes to bytes (pictures, sound, etc) how to catch the response from API.
Okay, if I understand what you are trying to do is to make an Ajax call from a web page to the Twitter API and post/retrieve tweets and other info from Twitter.
Since the release of the API v1.1, Twitter has deprecated the v1.0 API and one of the major changes in 1.1 was Authentication Required on all Endpoints
And to do this from JavaScript and jQuery is quite possible (albeit very cumbersome, difficult and requires the use of many 3rd party JS libraries to HMAC Hash your data and keys and calculate content lengths on the client side before making your Request. Twitter API does not support CORS but does support JSONP for these kind of Ajax requests. But this is not recommended - since doing this on the client side will require you to have your Twitter App Access Keys - Private keys - embedded in your script files - which is basically a big NO-NO. And hence a server side solutions to generate your oAuth tokens is recommended. But once you have achieved that, it may be easier to get the token on your script and make Ajax calls using that from the browser. But I haven't gone that far in my research.
Also, this is based off of my research in Mid 2013 when my Twitter Ajax widgets stopped working because of this change and I gave up trying to fix it using that route after I realized it would compromise my security keys. Things may have changed since then.
If you are still interested to find a solution, this walkthrough would be a good place to start learning about Twitter's oAuth and how the Access Tokens are generated: https://dev.twitter.com/docs/auth/oauth
I need to offer a web service that my clients can use on their web sites with AJAX. They are not able to call my web service because of XSS preventions. The clients can not make a proxy to access my web service.
I am trying to make a javascript library on my server that they could include in their site, which would in turn call the web service on the server. Somehow it does not seem to work.
The server is located at Google App Engine.
So the question is: How can I make a javascript library on my server that uses backend on that server and remote users can use it? Much like google maps js API works?
You should use Cross Origin Resource Sharing instead, just set CORS http headers for your web service.
Access-Control-Allow-Origin: http://clientsite.com http://client.website.com
Same origin policy is dependant on document origin therefore providing a JavaScript library will not help.
Two possibilities:
have your javascript library create an iframe pointed at your server. Communicate between the code running in that iframe and the 3rd-party site via the best crosspage communication for the browser you're on. Google's Closure library has a class called CrossPageChannel that works very well for this. Put the bulk of your logic in the iframe. This can be nice because it'll prevent the 3rd-party site from doing anything that isn't well-defined by the messages you pass across the iframe boundary.
use JSONP to get data from your server and keep all the logic in the javascript library.
On this page: http://code.google.com/apis/accounts/docs/OAuth2UserAgent.html Google gives instructions for doing oauth with client side applications that talk to their apis.
One step is to call their token validation api. But if I want to do this from javascript, it would require an ajax request which is cross domain.
It seems like with all the improvements to cross domain stuff recently this should be possible, but I'm not figuring it out. Any pointers would be helpful.
If you want a completely browser-based solution, you should consider using the Google APIs JavaScript client. Here is the documentation on how to do auth using that library: https://code.google.com/p/google-api-javascript-client/wiki/Authentication
What is the best way to determine if a request being made to my REST service originated from a web client. I know I can look at the user-agent, but my concern is that is very easy to spoof.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
My site is built entirely in HTML and Javascript, any suggestions?
Or is there a good way in Javascript to store a hidden username / password I can use just for my website, without it being displayed to the public?
Thanks,
Adam
Anything put in the javascript can be found by using a debugger, such as Firebug, so even though it isn't visible to the user, it can be found by a user.
But, if the javascript first calls to a REST service to get an encrypted token, then the token, which has a timestamp encrypted within it, could be the password, so you then pass the username and token to call the rest of the REST services.
Your server could then validate that it had created the token and that it is not expired, and that the username matches what was encrypted in the token.
But, this depends on if you have any control over the REST service.
The reason I want to know who originated the request is because of the following. It is natively built into web-browser that you can't do cross-domain requests. Therefore I don't need to worry about the authentication, because I know the request originated from my website.
This is not a good assumption. For the reasons you already gave (easily spoofed User-Agent), anyone could make a request to your application. You can even disable cross origin policy in firefox and chrome from the client side - so even if you could verify the request came from a browser, it's still possible to get around your security measures:
Disable same origin policy in Chrome
There are a couple of standard ways to implement security for this kind of service (as James mentioned, assuming you have control over the REST service).
Use Basic Authentication - If your application is communicating with the WCF service via HTTPS, basic authentication is probably the easiest method. See this question
If both your website and your WCF service are implemented using .NET, and your ASP.NET web application is using Forms Authentication, you could share the Forms Auth cookie and use that for authentication. See this question