I am redesigning a web project that requires a lot of involved data entry. I would like to make use of ASP.NET's ajax functionality to improve the user experience. But a large portion of my user base is still using Internet Explorer 7, which has caused problems for us in the past when it comes to AJAX functionality. We cannot request they upgrade, and not supporting them is not an option.
Is there an effective way to disable AJAX functionality for those users on Internet Explorer 7 and provide the full ajax experience for users on more compliant browsers?
If you use Modernizr, it will accurately detect which browser you have, and set a specific css value in the html tag of the page. You can then use jquery (or just DOM api) to check the browser version and set a flag that disables your ajax.
Related
Essentially, I need for my ASP.NET application to programmatically fill out a web form on another website for my users and then display that website to them. There are no other requirements, so I am open to any suggestions for making this happen.
Is this even possible?
It can be using ASP.NET MVC or WebForms.
No, this is technically not possible. Form fields values may only be set either explicitly in the HTML or via JavaScript. Filling out a third-party form would not allow modifications to HTML (which is generated by the third-party) and any JavaScript solution would require that third-party running your JavaScript, which you obviously cannot force them to do.
You could perhaps embed the site in a frame within your site, which would then allow you to run JS on your site that could manipulate the site in the frame. However, this would require that the third-party allows their site to be framed in the first place and that they do not employ a Content Security Policy that would prevent your JS from running against their site. What you would be doing is basically an exploit, and if they have any reasonable security in place, it won't work because of that.
I'm building a web app that uses a lot of CSS3 and session storage. My goal is to deny users of older browsers by redirecting them to a "we don't support your browser" page. I'm thinking of using an http module that looks at the incoming request. In the client page I would encode a hidden field that contains the user agent version.
I want this to work for both regular aspx requests and ajax requests to asmx files. What would a good method to do this be?
You may use HttpRequest.Browser property to detects browser type in ASP.NET and have a look at article by Scott Mitchell - Performing Browser Detection Using ASP.NET.
I don't think you would need to encode anything onto the page. Create a module that detects the browser, or the version of javascript the browser supports (for example), using the Http.Browser capabilities.
I am wondering if some mobile browsers are not able to handle the html hidden fields properly. (i.e. fails to pass the value on submitting the form)
If that is the case then is it safe to assume that the browser will not able able to browse through ASP.NET pages with postbacks as postback uses hidden fields?
Thanks in advance.
Felix
AFAIK this is not an issue as the recommendation from Microsoft is to switch to normal ASP.NET controls. Actually, even the System.Web.Mobile.dll assembly is being deprecated.
I would like to have a list of browsers which don't support a website created based on .net.
Thanks.
ASP.NET web sites emit HTML, CSS and javascript (just like other technologies), and as such should be readable by ALL browsers. The technology used to host the site should have little impact on its consumption by browser clients.
The ony real concern is when non-conforming HTML or CSS is present and the web site doesn't render properly.
All of them support ASP.Net. More often you will need to look at the browser market share and all browsers mentioned in the report support ASP.Net very so you can be rest assured that your asp.net site will be usable for almost everybody on earth.
alt text http://marketshare.hitslink.com/chartfx62/temp/CFT0220_014339215AE.png
ASP.NET is server side, so your answer is any and every web browser.
I was wondering if it is possible to do a RedirectToProvider and have the resulting OpenID provider page displayed in an iFrame. This would make the authentication flow seem a lot more streamlined.
I am using the DotNetOpenID library in ASP.NET MVC (VB).
This next part is sort of a seperate question, but is related.
I am using Ajax.BeginForm for the OpenID sign in form, however the RedirectToProvider fails here for some reason. Does DotNetOpenId not work with MVC and AJAX?
Yes, DotNetOpenId supports iframes, MVC and Ajax. The OpenIdAjaxTextBox control that ships with the library and is shown used in one of the samples demonstrates this. It does not use iframes to display anything. It uses them with checkid_immediate to attempt implicit login without any user interaction, which is the only iframe-scenario that OpenID intends to support.
The IAuthenticationRequest.RedirectToProvider method internally invokes the ASP.NET Response.Redirect, which itself throws a ThreadAbortException, which might be why it seems to be failing for you, when in fact it's probably working by design, but that design conflicts with what you're probably trying to do.
There are various approaches to take to get what you want done, but as Workshop Alex has already suggested, there is a security concern with hosting the Provider's page in an iframe. It's not that the RP can access or mettle with the content of the iframe, because as EFraim said unless the browser has bugs that would not be allowed anyway. The two problems with it are Clickjacking and that you're training the user to be phished, since he will likely be providing his login credentials to his OP while the RP's URL is in the location bar, which is a bad thing.
And in fact, major OPs now deliberately refuse to work when they are activated within an iframe, so after the work to get it all to behave the way you want, you'd likely be disappointed that most of your customers won't be able to login.
Also as you point out, popup windows, when done properly, can help keep the experience user friendly. You can achieve this a few different ways with DotNetOpenId as well. The ASP.NET controls that come with the library have this feature built in and can be activated by just setting a property on the control. But since you're using ASP.NET MVC (I think), here's how you can do it yourself:
When the user clicks the Login button on your page, rather than POSTing to the current window, have Javascript that opens an appropriately sized popup window at a URL like http://yoursite.com/openid/redirect?id=userSuppliedIdentifier.
Your OpenID controller's Redirect action will read that ID, do an OpenIdRelyingParty.CreateRequest on that ID, and return IAuthenticationRequest.RedirectingResponse.AsActionResult() (MVC style). Note you can pass your own URL to CreateRequest for a returnTo url if you want the OP's response to come back to a different method on your OpenID controller.
When the assertion comes back, your controller should send down javascript that closes the popup window and (as necessary) communicates back to the main window to update its state for the logged in user.
This whole process is completely automated in the ASP.NET controls that DotNetOpenId ships with. It's unfortunate that ASP.NET MVC cannot be made as modularized as ASP.NET web forms so that you don't have to do all this work yourself. Of course, the MVC sample that DotNetOpenId ships with could be made to show how to do popup behavior in a future version. If you want that, file a wish for it.
Question is, would the OpenID provider consider this a security risk or not? If the provider page is inside an IFrame then the surrounding page can have some control over what's happening inside this frame, including an attempt to capture some of the information. It could be a possible exploit risk. Do keep in mind that OpenID providers are very paranoid about these things and might even attempt to break out from such an IFrame or just deny any further login actions. It's a risk that they might not want to take.
Is it possible? If it is, I think the answer also depends on the provider.