I want to write a custom HTTP Handler in ASP.Net (I'm using C# currently) that filters all requests to, say, .aspx files, and then, depending on the page name that comes with the requests, I redirect the user to a page.
So far, I've written a handler that filter "*", that is, everything. Let's say I receive a request for "Page.aspx", and want to send the user to "AnotherPage.aspx". So I call Redirect on that response and pass "AnotherPage.aspx" as the new page. The problem is that this will once more trigger my handler, which will do nothing. This will leave the user without any response.
So, is there a way to send the request to the other handlers (cascade the message) once I've dealt with it?
Thanks,
Bruno
Page.PreviousPage or Page.IsCrossPagePostBack should let you know.
Since Mark hasn't provided a full anwer containing the advice on MVC, here it goes what I learned:
ASP.Net MVC can do that. In fact, ASP.Net MVC was designed for that purpose: with MVC you can map different sub-links in your website to the same Controller, which will then process the request and send a view (page) back to the user. This technique is called Url Routing and is explained in ScottGu's blog quite well.
Scott's also have other articles describing MVC, which are worth checking out.
Related
When a user has completed a form the user is redirected to the thank you page. The thank you page shall render it's view, but also download a file (pdf / a stream).
I would prefer to do this without using javascript like this
return both a file and a rendered view in an MVC3 Controller action and I would prefer to get the Save As dialog.
Has MVC any conventions that can handle this?
As #BenRobinson pointed out, you can't return two responses from a single request. No, MVC doesn't have any conventions to handle this because it's a fundamental limitation of the platform you're developing on, the Internet, and specifically the TCP/IP and HTTP protocols.
Fundamentally, the web revolves around what's called the request-response cycle. A client (usually a web browser) issues a request to a server, and that server responds with the requested resource. What you're talking about would be akin to request-response-response, which is not possible. The server cannot just up and send a response to a client without first receiving a request.
As a result, your options are:
Use JavaScript to programmatically issue another request, such as by setting location.href as the accepted answer on your linked question suggests.
Provide a link/button/whatever to allow the user to initiate a request for the file manually.
That's it. Either way, you need a new request, either initiated by JavaScript or the end user to get the file.
Did you tried meta refresh Trick.
<META HTTP-EQUIV='REFRESH' CONTENT='5;URL=http://www.example.com/test.txt'>
Remember to set the header Content-Disposition: attachment for the file that you want to download in browser.
I am working on a C# WebApi/MVC project that has a rather large workflow process for creating a user and placing in their required information.
There is about 10 major steps involved, in which it could technically take a user hours to fill out.
The first step takes standard basic information such as username, password, email, name, address etc.
What I would like to do is after this first step is successful, send a rest call that will create the basic user in the user table, and then prepare a session for the further steps in which when any field is filled out in the next steps, it will automatically send an ajax call and update the field in the database.
While this all sounds easy and simple in theory with the use of sessions, which I could do in MVC, I want to do this in WebApi with REST in which REST is supposed to be STATELESS.
Has anyone come across similar issues, and if so what do they recommend as an approach? The options I can currently think of are:
-Ditch the REST for standard MVC for this process and leave WebAPI for only Reads instead of Writes as the only Write process is the inital creation of users/accounts.
-Using Authentication tokens? But can this handle this process successfully?
-Once the user is created, take the username/password for every REST call as the auth to the WebAPI? Store the User/Password in MVC session and directly call the API from MVC, mobile applications would just store the username/password in the application and call the WebAPI (I think this is the most appropriate)
Can anyone tell me if any of those options are the best practice, or does anyone have a better best practice/process for these things? I would prefer to write things once to cover Web and Mobile as much as possible rather than having to duplicate processes.
Thanks in advance!!!
I would consider to modify regular WebAPI OWIN register flow.
Collect basic user info and post to Web API via Ajax. If succeeded -
send OWIN token back to the caller in HTTP header.
Proceed to extra
steps for user info updates (via HTTP PUT for example) and put the
token in authenticate header. Mark WebAPI update procedure with
Authorize attribute.
This blog post could help to setup WebAPI to issue and accept bearer tokens.
In a Website environment how do you make an ajax post to Handler.ashx secure and how do you stop people calling that handler.ashx directly and putting rubbish in and possibly breaking things server side?
With firefox and firebug you can pretty much hack the post quickly and easily.
I was thinking of these ideas.
In the handler check if you are logged in.
List item on the load of the site create a unique ID is saved as a cookie and
when the handler is called then that ID must exist in the Ajax and
the handler
List item the ajax call must come from a certain page
Do you have any other ideas?
Thanks
Short answer
Use authentication (Windows, Forms, etc) and validate your input.
Slightly longer answer
If your site is configured with an authentication provider, your handler will follow the same rules.
You should always validate any user input or web service input. Don't assume that your client is giving you pristine input. As you have mentioned, anyone with basic web development skills can spoof a POST. Keep that in mind when validating.
I have a situation whereby I need to redirect a user from a page on my server to a page on another server. In this redirect I need to also send some xml to the server I am redirecting to. This xml file could be quite long so just sending it in the querystring isn't an option.
I have tried attaching the xml in a header but the header doesn't seem to make it to the other end.
I know how to programmatically create requests to send xml and how to redirect, just not sure how to do both at the same time.
In short, I need the xml to piggy-back on the redirect. This redirect will be done from within an MVC Action.
Thanks in advance.
Edit
I have come up with the following potential solution to my problem. Unfortunately it does utilise two requests which I had hoped to avoid.
Basically I send the xml file as a header of a post request which also contains a session id. This is sent asynchronously.
I then redirect the user, passing the same sessionid in the querystring. This acts as a token to link one request to the other. I just need to wait now and find out if the other party are willing to work using two requests.
I also looked in to using an additional page that I could redirect the user to which could contain Javascript to perform an additional form post to the other server with a form that would contain just a single field containing the xml fragment, but this was excluded as a possibility by my boss (rightly so as it seems like a bit of a hack).
Are there any obvious or non-obvious drawbacks to my proposed method, other than the obvious possibility of a race condition between the 2 requests?
You could redirect to http://otherServer/handlerPage.aspx?xmlSource=http%3A%2F%2FfirstServer%2FxmlSource.aspx%3FparameterForXml1%3Dfoo%26parameterForXml2%3Dbar
Then at http://otherServer/handlerPage.aspx the xmlSource parameter is http://firstServer/xmlSource.aspx?parameterForXml1=foo¶meterForXml2=bar which can be used to obtain the XML.
I'm creating a page that makes multiple AJAX form posts without a page refresh.
I would like to use the ASP.NET MVC HTML.AntiForgeryToken() helper to secure the form against CSRF attacks. I think that each form on the page can share the same token, but will it allow multiple requests with the same token? If not is there a way to get a new token or some other way to secure the forms?
You can share the same token. Of course, as a general rule, it's highly recommended to wrap your Ajax calls in a unified method that concatenates the CSRF token to the request (be it GET or POST although POST is safer and much more correct from architectural perspective), so when you make Ajax calls you focus on the business input values only, and don't need to worry about CSRF.
Edit: Read this nice post & sample of auto-wrapping Ajax for CSRF protection using jQuery 1.5 and up: http://www.codethinked.com/aspnet-mvc-ajax-csrf-protection-with-jquery-15
I will suggest to read these articles:
http://blog.stevensanderson.com/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
http://msmvps.com/blogs/luisabreu/archive/2009/02/09/the-mvc-platform-the-new-anti-forgery-token.aspx
So to answer your question - it will depend upon how you are doing it. When you use AntiForgeryToken to embed the token, it would generate (new) token in hidden field as well as cookie. And CRSF attack is detected by comparing them provided you have marked your action method (for POST) with ValidateAntiForgeryToken attribute. Now, its important that new token should be created for each request. So when you do you AJAX form posts, cookie is going to be set with new token value and you must ensure that the AJAX response contain new token field and you update it on browser side. I will also suggest that you use different salts for different forms for better protection.