We've recently been working on a fairly modern web app and are ready to being deploying it for alpha/beta and getting some real-world experience with it.
We have ASP.Net based web services (Web Api) and a JavaScript front-end which is 100% client-side MVC using backbone.
We have purchased our domain name, and for the sake of this question our deployment looks like this:
webservices.mydomain.com (Webservices)
mydomain.com (JavaScript front-end)
If the JavaScript attempts to talk to the webservices on the sub-domain we blow up with cross domain issues, I've played around with CORS but am not satisfied with the cross browser support so I'm counting this out as an option.
On our development PC's we have used an IIS reverse proxy to forward all requests to mydomain.com/webservices to webservices.mydomain.com - Which solves all our problems as the browser thinks everything is on the same domain.
So my question is, in a public deployment, how is this issue most commonly solved? Is a reverse proxy the right way to do it? If so is there any hosted services that offer a reverse proxy for this situation? Are there better ways of deploying this?
I want to use CloudFront CDN as all our servers/services are hosted with Amazon, I'm really struggling to find info on if a CDN can support this type of setup though.
Thanks
What you are trying to do is cross-subdomain calls, and not entirely cross-domain.
That are tricks for that: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/
As asked how this issue is most commonly solved. My answer is: this issue is commonly AVOIDED. In real world you would setup your domains such as you don't need to make such ways around just to get your application running or setup a proxy server to forward the calls for you. JSONP is also a hack-ish solution.
To allow this Web Service to be called from script, using ASP.NET AJAX, add the following line to the first web service code-behind :
[System.Web.Script.Services.ScriptService]
You can simply use JSONP for AJAX requests then cross-domain is not an issue.
If AJAX requests return some HTML, it can be escaped into a JSON string.
The second one is a little bit awkward, though.
You have 2/3 layers
in the web service code-behin class, add this atribute : <System.Web.Script.Services.ScriptService()> _
maybe you need to add this in the System.web node of your web.config:
<webServices>
<protocols>
<add name="AnyHttpSoap"/>
<add name="HttpPost"/>
<add name="HttpGet"/>
</protocols>
</webServices>
In the client-side interface
-Add web reference to the service on the subdomain (exmpl. webservices.mydomain.com/svc.asmx)
Visual studio make the "proxy class"
-add functionality in the masterpage's|page's|control's code behin
-Simply call this functions from client-side
You can use AJAX functionality with scriptmanager or use another system like JQuery.
If your main website is compiled in .NET 3.5 or older, you need to add a reference to the namespace System.Web.Extensions and declare it in your web.config file.
If you have the bandwidth (network I/O and CPU) to handle this, a reverse proxy is an excellent solution. A good reverse proxy will even cache static calls to help mitigate the network delay introduced by the proxy.
The other option is to setup the proper cross domain policy files and/or headers. Doing this in some cloud providers can be hard or even impossible. I recently ran into issues with font files and IE not being happy with cross domain calls. We could not get the cloud storage provider we were using to set the correct headers, so we hosted them locally rather than have to deal with a reverse proxy.
easyXDM is a cross domain Javascript plugin that may be worth exploring. It makes use of standards when the browser supports them, and abstracts away the various hacks required when the browser doesn't support the standards. From easyXDM.net:
easyXDM is a Javascript library that enables you as a developer to
easily work around the limitation set in place by the Same Origin
Policy, in turn making it easy to communicate and expose javascript
API’s across domain boundaries.
At the core easyXDM provides a transport stack capable of passing
string based messages between two windows, a consumer (the main
document) and a provider (a document included using an iframe). It
does this by using one of several available techniques, always
selecting the most efficient one for the current browser. For all
implementations the transport stack offers bi-directionality,
reliability, queueing and sender-verification.
One of the goals of easyXDM is to support all browsers that are in
common use, and to provide the same features for all. One of the
strategies for reaching this is to follow defined standards, plus
using feature detection to assure the use of the most efficient one.
To quote easy XDM's author:
...sites like LinkedIn, Twitter and Disqus as well as applications run
by Nokia and others have built their applications on top of the
messaging framework provided by easyXDM.
So easyXDM is clearly not some poxy hack, but I admit its a big dependency to take on your project.
The current state of the web is that if you want to push the envelop, you have to use feature detection and polyfills, or simply force your users to upgrade to an HTML5 browser. If that makes you squirm, you're not alone, but the polyfills are a kind of temporary evil needed to get from where the web is to where we'd like it to be.
See also this SO question.
Related
I realise that this is going to be a fairly niche requirement and will almost certainly raise a few "WTF's" but here goes...
Within an ASP.NET Webforms application I need to serve static content from a local client machine in order to reduce up-front bandwidth requirements as much as possible (Security policy has disabled all Browser caching). The idea is to serve CSS, images and JavaScript files from a location on the local file system referenced by filesystem links from within the Web application (Yes, I know, WTF's galore but that's how it is). The application itself will effectively be an Intranet app that's hosted externally from a client but restricted by IP range along with standard username/password security. So it's pretty much a hybrid Internet/Intranet application but we can easily roll out packages of files to client machines. I am not suggesting that we expect nor require public clients to download packages of files. We have control to an extent over the client machines in terms of the local filesystem and so on but we cannot change the caching policy.
We're using UpdatePanel controls to perform partial page updates which obviously means that we need to Microsoft AJAX JavaScript files. Presently these are being served (as standard) by a standard resource handler within IIS/ASP.NET. Ideally I would like to be able to take these JS files and reference them statically from a client machine, and no longer serve them via an AXD.
My questions are:Is this possible?If it is possible, how do we go about doing so?
In order to attempt to pre-empt some WTF's the requirement stems from attempting to service a requirement with as little time and effort as possible whilst a more suitable solution is developed. I'm aware that we can lighten the load, we can switch to jQuery AJAX updates, we can rewrite the front-end in MVC etc. but my question is related to what we can quickly deploy with our existing application architecture.
Many thanks in advance :)
Lorna,
maybe your security team is going crazy. What is the difference between serving a dynamic HTML generated by the server and a dynamic JS generated by the server?
It does not make any sense. You should try talking them out of it.
what is the average size of pages and viewstate data. you might need to store viewstate in sqlserver rather than sending it to client browser every time.
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.
I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.
I am making a making a new asp.net web forms site and would like to beautify my urls - I want to accept a url like this one "www.mysite.com/1-2,3" and turn it one like this "www.mysite.com/page.aspx?a=1&b=2&c=3". Which option is best for this task - IIS7 Url Rewriting or Routing in terms of performance and ease of maintenance. Btw I am planning to use medium trust shared hosting IIS7, maybe 6.
In the past I used PHP's mod_rewrite, which I was quite happy with, however now this whole site is being translated to ASP.NET, and I don't know which option to pick.
PS - I have already read this and this, however didn't find it clear enough for my problem.
I would make a strong argument for using routing. It keeps the request-resource resolution logic within your application, so it's very easy to add application-dependent logic when you need, and it eliminates the need to maintain synchronization between your application and a separate configuration resource.
Routing works great with traditional webforms.
URL rewriting is often (though not always) a compensation for a problem, rather than a solution - server software and frameworks still built around the older notion of web pages, which represent physical resources. However, web applications should react to requests as commands; but only relatively recent, modern web frameworks have begun to support that model natively. Routing is one of those developments.
I would strongly suggest to use routing,
it will in fact be more integrated with webforms in next version of the framework.
URL rewriting is more of a "hack" due to the lack of the routing in the first place. If you already have a project that you want to "shine up", then url rewriting will do just fine.
But when starting from scratch, I would definitely use routing.
Routing hides you application structure and makes you think more of your urls, as path to the content that you want to show, opposed to the path to some page with params.
And you don't have to keep track of 2 things when changing stuff, like you would with rewriting.
more in this article
IIS 5/6 used ISAPI filtering which was basically the equivalent of mod_rewrite for IIS. I hear that IIS7's url rewriting is a lot easier to manage and configure than ISAPI.
Well it depends on whether you're using classic ASP.Net or the new MVC framework. I don't have any experience with the MVC framework, but it sounds like it supports what you're looking for right out of the box.
On the classic ASP.Net side of things, we're currently using an IIS extension called ISAPI_Rewrite. It behaves similarly to Apache's mod_Rewrite and they have a free version you can use that has most of the power of the paid version ($100).
We have a web application that uses AJAX to talk to an ASP.NET web service. We would like to write another version that can be used offline. We need to be able to re-use our existing code as much as possible. What approaches should we consider?
The app is currently using XmlHttpRequest to get dynamic data from the server. Obviously the offline version will not be able to talk to the server, but it does need to talk to something! I'm sure installing IIS or Cassini on the client would work, but I was hoping for a simpler solution. Is there no other way for JavaScript to talk to some external code?
There are plenty offline web apps nowaday. It simply evolve from AJAX.
For example:
WoaS (wiki on a stick / stickwiki), Tiddly Wiki,
Google doc and Gmail is going to be offline.
You don't need a webserver to run these webapps in offline mode. Just store the required data, scripts on the client side (usually as XML).
One of the possibilities would be to use Cassini. This is a web server that acts as a host for the ASP.Net runtime. You can host Cassini in a Windows application or a Windows Service. In this scenario you do not have to rewrite the web app and the web service.
Most other solutions do require a rewrite of both your web app and your web service. Depending on the way you have written the existing app you can reuse more or less code.
Have you considered HTML5 with application cache and offline storage?
If you hope to create an "offline" version of your package your biggest issue by far will be the need to install your site into a local copy of IIS (registering a virtual directory, etc.). I pursued this briefly a few years ago and gave up in frustration. It can be done: a number of software vendors such as DevExpress do this so you have local copies of their demonstration projects. Indeed, I was able to do this. The problem was the classic "it works on my computer" syndrome. There was simply no way to guarantee that most of my end-users had anywhere near the technical proficiency to make this work.
Thus, I would strongly recommend that you not pursue this path unless you have very technically proficient users and a huge support staff.
But there is one more very important question: did you abstract all data access code to a DAL? If not, then you have a lot of work to do in managing data access as well.
Update: user "Rine" has recommended Cassini. I just wanted to let you know that I pursued Cassini and another 3rd-party web server as well. I think that there are licensing issues with Cassini but may be wrong - it has been awhile. However, I do distinctly remember running into barrier after barrier with this approach and very little documentation to help me out.
if you want a web application run offline, you need a webserver (IIS for ASP) bound to the localhost (127.0.0.1) address. After this so can access your web application by typing http://127.0.0.1/ in your web browser the same way as you do online.
If your AJAX relies on XMLHttpRequest's, you can:
Make the static versions of XML's you get over XMLHttpRequest and put then into a folder on disk.
Rewrite your XMLHttpRequest URL's so that they point to files on disk.
Rewrite your XMLHttpRequest's so that they don't check status (it's always 0 for the file:// protocol.
All JScript works on file:// pages as well as on http:// ones.
Of course it's not the best way to develop static pages, but it may save you some time on rewriting.
I havent come across any framework specifically built for asp.net like the ones available for PHP or RoR.
Here is a good article by Steven to get you started with HTML 5 and ASP.Net Creating HTML 5 Offline application
Obviously the offline version will not be able to talk to the server, but it does need to talk to something!
Enter HTML5 LocalStorage. It works like a database and enables you to put data on your client. Indeed you have to rework parts of your code in javascript and transmit it to the client, but then it would work offline.
Local Storage works like this:
- Setter: window.localStorage.setItem(KEY, VALUE)
- Getter: window.localStorage.getItem(KEY)
- Remove: window.localStorage.removeItem(KEY)
To get the main page working offline you need to create a manifest. This is used to store complete sites on the client. Please refer to this for more information about manifests:
http://diveintohtml5.info/offline.html
You want to build a web application to work offline?? It can't be done.
You could split the interface code from the rest (in diferent dlls) and create a windows application to mimic the behaviour of your web application. This way you have 2 distinct user interfaces but the same code for business rules and data access.
I don't really see any other way...