Is it possible to post data from an asp.net application in one domain to another application on a different domain?
I've seen some of the posts where people mention some rather strange ways to inject forms into the response stream, but this seems overkill.
Is it possible and what is the best way to achieve it without hacking Asp.net to death?
Thanks,
Jacques
It's absolutely possible, and pretty easy to do.
Browser posts data to your .net app
Your app uses the HttpWebRequest object to post data to the 3rd party site
3rd party site gives data back to your app or simply accepts post.
Your app responds to the browser with whatever you need.
I have no idea why you would "inject forms into the response stream" or do anything funky like that. Perhaps you could add a bit more about your requirements.
Chris.
If you have access to both applications then the best way is to do it server side.
So make a web service available and consume it from the posting application.
or
Use httpwebrequest server side, see link below.
http://www.netomatix.com/httppostdata.aspx
On the client you could use a library such as http://easyxdm.net/wp/ - though there is a bit of a learning curve.
Here are a couple of links that may help you if you dont want to use the above routes and are prepared to edit your asp.net pages.
http://blog.dmbcllc.com/2009/11/11/asp-net-cross-domain-form-submission/
Cross-Domain Posting in ASP.Net loses Form Fields
Related
I am writing a simple web page for our existing web site that will only be used by the web site admin to delete all images from a certain directory on the server. He would browse to this page from his web browser (not to be consumed by any external services as of right now). I was thinking of creating another ASPX page (obviously not linked from or to anywhere) that implemented this. Is this considered a RESTful API? If not, what would be, and would it be a more elegant solution than what I'm proposing?
I realize this is an extremely simplistic example, but I'm trying to understand what RESTful really means and if it would benefit our existing infrastructure in any meaningful way, so that's kind of the purpose of this question.
Our website is written entirely in ASP.NET 2.0 WebForms.
It depends on your URL structure. a classic REST API call would be to, say:
/images/delete
You would then send a Post as DELETE or just GET or POST to this to do what you need. That's more the RESTful way. REST isn't so much what you are doing with the method as the structure of that method. I hope that makes sense :).
I am trying to implement a service to download a image file. The code does nothing but upload a file to the response with each client request.
There are no SOAP messages involved but I am planning to implement it as ASP.NET web service. It can also be implement as ASP.NET website but since it has no view (forms, html etc) I planned to implement a web-service.
Is this a better approach? Does ASP.NET Website offer better performance that a Web-service?
Which one would be better is this situation?
I'd suggest using an ASHX handler. If you haven't heard of them before, you can think of them as a code-behind file without the ASPX view. Generally speaking they are considered more light weight than a web service.
Well first off, do you need code to handle the image request at all? Is the image processed in some way relative to the request, or is it static? Why do you want to implement this in code instead of simply serving a static image over http? Are there security considerations to be taken into account, e.g. serving images to particular users based on their credentials?
Unless you can give us a little more detail of your requirements it's impossible to make any concrete judgement or recommendation.
I am trying to create a static HTML page which has a <form> which posts to a 3rd-party ASP.NET website.
Is this possible when the target website uses ASP.NET webforms?
This is absolutely possible. You can issue a POST to any website, anywhere. (Keep this in mind when you're designing an application that accepts POSTs from a web merchant such as PayPal ;-) make sure you know where the POST is coming from.)
Whether or not the website will accept your request, of course, is up to however the server-side code was programmed. If you're POSTing to an ASP.NET WebForms app and the app wasn't designed to accept third-party POSTs, then you're going to have a hard time making your POST parameters look like they came fro ma WebForms page. For example, the website will be looking for the encrypted viewstate, among other things.
You could use firebug or some other tool to sniff the POST data from the webforms app, and then replicate that data in your static HTML page .... it might work.
Do you have any programming control over the ASP.NET Webforms app at all?
check out this question:
How to POST Data to another web application (cross domain)
Let me know, if you need help with my implementation.
Many hosting companies let you define which page will be shown to the user if the user goes to a page that does not exist. If you define some .aspx page then it will execute and be shown.
My question is, why not use this for routing. since I can parse the users URL and then do a server.transfer to the page I want. I checked and there is no redirect sent to the client and the http headers are HTTP/1.1 200 OK.
So, is this a good idea for servers that don't have ASP.NET 3.5 SP1 or if you are not using MVC?
Thanks
You "can" do that, but why not just create an HttpModule and handle the routing there? That's how most of the URL rewriting systems work (in actuality, it's also how the MVC routing works since global.asax is just a pre-build HttpModule with a few extras).
The big thing with relying on that kind of server handling you describe is that you really aren't in control of it, and it is a hackish mechanism... by that I mean you are taking a function of the web server that has a specific purpose and design and laying a different meaning and function on top of it... which means you now have no built in handling for an actual 404 error. Plus, the mechanism you are contemplating is harder to adapt to your purpose than just using the other options available to you.
Unless you need something special from routing, you should consider using an existing routing component such as Mod-Rewrite or one of the dozen or so other popular URL rewriters that were built before the MVC routing engine was implemented and work fine in older versions of asp.net. There are also numerous tutorials on using HttpModules, HttpHandlers, and various other techniques to do routing in asp.net webform environments.
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.