I need to develop a web service to accept and save XML files transfered via POST requests. The chosen platform is IIS - problem is, I have zero experience handling ASP.net so far. While I think that handling the request object and saving it to the system should be easily doable, I am very insecure how to deal with the components of IIS itself.
AFAIK the source system (SAP) throws a POST directly at an URL, so I don't neccessarily need an actual form or page, but how do I weave it all together?
Do I still need a page or just a handler, how would I register it, to what extension?
I would be very happy if someone could give me a little jump start and point me in the right direction.
Thanks in advance,
Christian
Related
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
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.
When clicking the save button on a asp.net web form page, I get the following immediately:
The specified URL cannot be found
This does not happen when I try this using a browser on the web server.
Has anyone run across this problem before? Is this some kind of security issue?
More information. I tried a test page that included all of the form fields and a button that didn't do anything but write to a log4net log. Same problem on the button click. This is just weird.
Found the solution to this!!! Turns out the firewall was blocking request that had more then 40 parameters in the query string.
Could you provide a bit more information?
This could be caused by a lot of things:
Is IIS configured properly for the site? Authentication, host header settings?
Did you try http://localhost/.. on the webserver or did you use the webserver's host name?
Are you redirecting the user? What are you doing in the button event?
Are you using URL routing? Or a handler that might be causing problems?
What version of the .NET framework are you running? 1.1 / 2.0 / higher?
Does the page include javascript that could cause unexpected results?
Checked for crazy stuff in your web.config?
Sometimes it's a good idea to take a step back and create a new ASPX page and test if that one works. Start from a predictable scenario and move towards your current scenario in baby steps.
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.
The only thing I was able to find on the subject was a posting from 1997
(http://insecure.org/sploits/microsoft.asp.iis.html), so I was hoping someone on here might have more recent knowledge on this topic:
Does anyone know if there are any known vulnerabilities in IIS6 that would allow a user to view an unprocessed ASP or ASPX page, outside of gaining control of the server?
IIS will serve raw asp or aspx only if those extensions are removed from application mappings for the site, or if you done some other dumb thing to configure it that way.
Why would you want unprocessed asp pages? You could just have a link that will escape the page and put it into a webpage for the user.
To me it would be a potential security risk, as, if you forgot and left a security vulnerability it would be seen.
If you didn't have your script mappings set up properly, this could be an issue, but that's more of a deploy-time concern, not a run-time concern.
I think any other vulnerabilities in this area would be app-related (picking a file to download server side...), not so much platform related.
Are you concerned about people being able to see your source code? If it is, I wouldn't worry too much about it, especially with .net and using code behind files, and a properly architectured n-tiered site.
Really, the only time this is a concern is if you have an error on your page and you spit out debugging code, even with classic asp.