There's a Javascript library for doing OAuth - called jsOAuth.
The examples that are available show it being used from within browsers. There are also some examples that claim to show how to use it from Node.js.
Can it also be used from ASP Classic / JScript ?
The key test would be:
can jsOAuth be used to post a Tweet on behalf of a user, from an ASP Classic page?
No, I don't think so.
The library has a couple problems that prevent it from being used as is, from an ASP-Classic page implemented in Javascript.
the basic syntax of the library assumes a require package and a well-known exports variable. These conventions aren't present in ASP Classic. Also it directly assigns properties to the global "this" object, which isn't directly possible in ASP Classic.
jsOAuth presumes the presence of the map method on all Array types.
jsOAuth instantiates XMLHttpRequest instances directly from the XMLHttpRequest constructor. This constructor is available in the Javascript execution environment within modern browsers, but it isn't available within ASP-Classic. The library could fall back to use new ActiveXObject("MSXML2.ServerXMLHTTP"), but it does not.
The library presumes asynchronous XMLHttpRequest operation. In a browser, that works just fine. But in ASP-Classic page, the page process ends, which means pending asynchronous calls are orphaned. In the ASP-Classic environment, it would be necessary to make synchronous calls to the OAuth-protected Service Provider.
So out of the box, not possible. The other major obstacle to using it within ASP Classic is the lack of suitable documentation and examples.
It is possible to modify the library to allow it to be used in ASP Classic; I've put together a modified version. I'll post it shortly.
Related
Currently, I'm using AjaxPro Framework (http://www.ajaxpro.info/) to call any methods in my web application from the client side.
But users have some serious problems using it. (e.g success callbacks don't work in Chrome. More info about the problems could be found at: AjaxPro is working locally, but on server I am getting .ashx errors)
I'd like to replace it with a framework that can:
Call any method in my code behind. Even if it's defined in a class library. In AjaxPro I could define a method anywhere and add [AjaxPro.AjaxMethod] attribute to it. Now the method could be called in any client-side js code, even if they were in two different classes.
Doen's depend on web forms. I could replace AjaxPro with ASP.Net Ajax by using ScriptManager and Add [WebMethod] attribute to my methods and call any other method in my solution from that page method. But I'm using .ascx files and Page methods cannot be defined in .ascx files (They have to be defined in .aspx web forms).
Preferably free. (I'd like to use it in YetAnotherForum project development). But if only a paid framework is available, I'll be glad to pay for it.
Is there any other Ajax framework which has the AjaxPro functionality?
I would recommend using jQuery. It is becoming the client javascript API to use. Even Microsoft seems to be inclining towards it in favor of their AJAX client side APIs. You can call any method in a page using the .ajax method, sample here. I have never tried it inside a UserControl, but as long as the method is decorated with a WebMethod attribute, I don't see why it wouldn't work.
I believe you have a fair choice.
Look at http://ajaxpatterns.org/DotNet_Ajax_Frameworks#Lists
At my new job we're using ajaxpro, however I also have come across issues and am currently researching alternatives.
I am making a site where users can reply to topics, open topics, etc. and when the user sends a message, I don't want to postback; it's ugly.
I'm using generic handlers right now but I am having some problems with it. Like updating GridView using UpdatePanel when XMLHttpRequest's onreadystate is changing.
I decided to use PageMethods but I also wanted to ask you.
Which is better, faster and more useful: PageMethods or Generic Handlers?
I don't think there would be much difference between the speed of Page methods and HTTP Handlers. However if you're worried about your application's performance, you should benchmark each option and choose what's best for you.
To answer the question, which is better or more useful, basically within the ASP.NET context you have three options, each with their pros and cons:
Page methods - all your code is contained in single Page, which is fine if the code is only used by that page. You should probably implement methods that return page-specific HTML snippets as Page methods. However if we are talking about reusable code, such as "Save Topic" or "Get Topics", you might want to consider externalizing this code elsewhere. I guarantee that as your application grows, you'll need those methods elsewhere in your application end as well.
Generic HTTP handlers - are lightweight, and great for code you need to call often throughout your application. Most often generic handlers are implemented to serve content, and I don't know what the best practice around this topic is, but to me POST ing to a generic handler to save data has a distinct smell. You'll also find that for related functionality (Save, Get single, Get many, etc.) you'll end up with a swarm of handlers, or a handler with a giant switch statement and a fuzzy contract based on query string and POST parameters. I wouldn't recommend this option to implement extensive AJAX application. For small bits and pieces it might suit your needs.
ASP.NET web services (or WCF) - The third option you did not mention in your questions are ASP.NET web services (.asmx). You can easily include them in your existing ASP.NET application without any additional framework dependencies. They offer a good balance between the options 1 and 2. On one hand you get reusability throughout your application, and even outside your application if you so choose, which Page methods cannot provide. On the other hand you can neatly bind together related functionality in meaningful ways, which tends to get messy with generic handlers. You can also interact with the services using SOAP XML, JSON or HTTP POST / Plaintext as needed.
And the wildcard option here is: Use ASP.NET MVC and jQuery. If you're looking to build a lean and mean web application and you generally find postbacks ugly, and you find stuff such as what exactly happens when the xmlhttprequest changes readystate interesting, it might provide you with a better experience overall. Maybe not for this project, but for the next one.
If you mean with generic handlers web service endpoints then you can make the following distinction:
You can use PageMethods if the functionality only needs to be available on that page only
You can use web service endpoints if you want to reuse the functionality.
Personally I practically always use web service endpoints (in my case ajax enabled WCF).
I cannot see why you shouldn't use generic handlers. I think they are best - simple and flexible.
I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.
Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).