I'm trying to figure out using AJAX with Razor Pages.
I've been searching the Web but each example I've found does something different, and most are incomplete or not for Razor Pages.
So far, I've been focusing on variations of something like this:
$.post('/?handler=Delete', 5, function (x) {
alert(x);
});
And then my page model looks like this:
public void OnPostDelete(int id)
{
}
I've tried variations on this but, so far, my C# code is not getting called.
Questions:
UPDATE:
So I've been working with this and this is what I have now:
$.ajax({
url: '?handler=Delete',
data: {
id: $(this).data('id')
}
})
.fail(function (e) {
// Error
alert(e.responseText); // Way too much info
})
.done(function () {
// Success
})
.always(function () {
// Always
});
And my handler:
public void OnGetDelete(int id)
{
}
This is in fact calling my handler and I finally got it to pass the id argument.
Since I have a bounty, here's what I'd like to see in an answer:
OnPostDelete(), the handler is not called. How would I do a post?Two suggestion:
1- add the page path in front of the url. (I am not sure if it is mentioned in your words).
$.post('/{page_path}/?handler=Delete', 5, function (x) {
alert(x);
});
2- Follow the route map rule. For example, there is the 'id' in your function. The page may have configured like @page "{id:int}". So the url should be something like
$.post('/{page_path}/{id}/?handler=Delete', 5, function (x) {
alert(x);
});
You could pass F12 to check the request in Network tab , you may see 400 bad request error.
Razor Pages are designed to be automatically protected from cross-site request forgery (CSRF/XSRF) attacks. You don’t have to write any additional code. Antiforgery token generation and validation is automatically included in Razor Pages. Here the request fails, there is no AntiForgeryToken present on the page.
For the question , you could add explicitly using @Html.AntiForgeryToken() To add AntiForgeryToken, we can use any of the approaches. Both the approaches add an input type hidden with name __RequestVerificationToken. The Ajax request should send the anti-forgery token in request header to the server. So, the modified Ajax request looks like,
@Html.AntiForgeryToken()
@section Scripts
{
<script>
$.ajax({
type: "POST",
url: "/?handler=Delete&id="+5,
beforeSend: function (xhr) {
xhr.setRequestHeader("XSRF-TOKEN",
$('input:hidden[name="__RequestVerificationToken"]').val());
},
success: function (x) {
alert(x);
},
failure: function (response) {
alert(response);
}
});
</script>
}
Since the script sends the token in a header called X-CSRF-TOKEN, configure the antiforgery service to look for the X-CSRF-TOKEN header:
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
services.AddAntiforgery(o => o.HeaderName = "XSRF-TOKEN");
}
Reference:https://www.talkingdotnet.com/handle-ajax-requests-in-asp-net-core-razor-pages/
This is how I like to do it:
Configure your Javascript
//If you're returning a object, configure it
var yourObject = {
field1: "value1",
field2: "value2"
};
//setup ajax
$.ajax({
data: yourObject,
type: "POST",
url: "urltoyourhandler/delete" //you can add other paramters here as well by doing ?parm=value
success: function(data){
//do success stuff here
//based off my handler code below:
if(data.success){
console.log("Success!");
}
else{
console.log("Failed for some reason!");
}
}
error: function(){
//do error stuff here
//gets called if there is a issue contacting the URL or if there is a server error like 500
}
});
Configuring your handler. For my CRUD operations, I like making a CRUD controller to handle everything
[BindProperty]
public YourClass Name { get; set; }
//set handler to only accept POST and set a URL for it. URL should be to the same folder you're in
//the 'delete' in route doesn't have to match the function name but it's less confusing if it does
[HttpPost, Route("RouteToThisHandler/delete)]
public async Task<IActionResult> Delete()
{
//verify data and the do something with it
//I like returning a JsonResult. Add whatever data you want. I like returning success
//with true or false and some other data if needed
return new JsonResult(new { success: true, importantInfo: "This is important" });
}
Ajax has more configuration options to give you more information about any server errors that occur
As for the anti-forgery token, Microsoft says:
Antiforgery middleware is added to the Dependency injection container when one of the following APIs is called in Startup.ConfigureServices:
- AddMvc
- MapRazorPages
- MapControllerRoute
- MapBlazorHub
Here is a Microsoft link about the anti-forgery token: https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-3.1
I investigated a few things, what happens when you pass a string from AJAX instead of an integer and how the different routes affect the call (see interesting note below if you've got time) But mostly, all I found is that Razor Pages are pretty forgiving and everything seemed to just work. Like I mentioned, even passing a string where an integer type id still hit the handler method (it just gave me a default(int))
I created this repo just for exploring: https://github.com/EntityAdam/RazorPageHandlers
The major blocker, as @Yan pointed out is the Anti-Forgery token. That is really the only thing that caused a handler not to hit a breakpoint. As was suggested, check your network tab for failed requests or the console for bum JavaScript code.
From your snippet, to change it to a OnPostDelete you would need to use the POST type in the AJAX call AND include the Anti-Forgery Token.
$.ajax({
type: 'POST',
headers: { "RequestVerificationToken": $('input[name="__RequestVerificationToken"]').val() },
url: '?handler=Delete',
data: {
id: $(this).data('id')
}
})
.fail(function (e) {
// Error
alert(e.responseText); // Way too much info
})
.done(function () {
// Success
})
.always(function () {
// Always
});
Another topic that I didn't see discussed is where is this token coming from? It's generated by Razor automagically whenever there is a <form> element. If you do not have a <form> element, you can generate tokens when you need them, check out the @functions {} block in this MSDN Article. There are also scenarios where CSRF is useless or not required and you could also turn anti-forgery off if you don't need it (That's an entirely different discussion).
My criticisms of the approach are opinions so take 'em or leave 'em.
For this demo, I used the following @page directive
@page "{id?}"
In the HTML part of the forms like:
<form method="post" asp-page-handler="Delete">
<input type="hidden" name="id" value="1" />
<button class="btn btn-danger">Delete</button>
</form>
I'm using the asp-page-handler tag helper to assist in generating the correct URL. For the Create handler, with that @page directive the tag helper comes up with a form target of /?handler=Create
If you swap out that @page directive with @page "{handler?}/{id:int?}", the tag helper figures out the route which is now /Delete. But guess what? The AJAX calls work with either @page directive, even though the URL in the AJAX is hard coded to ?handler=Delete'