I can no longer do POSTs to the WebAPI in MVC 4. The Post() method, however I make it, will not be invoked. If I send a GET, there are no problems at all.
public void Post()
{
}
That is how simple it is in the controller. I use Fiddler to send the Post, but no reaction. I use fiddler to send a GET to the same controller, and the GET method gets invoked.
I have looked around for hours, but cannot figure out where the problem is, let alone where to do the debugging, because any POST simply has a 500 (Internal Server Error) returned.
Any ideas on what is going on here?
I had two more methods in the controller, one called GatherZipCode() and another called RetrieveWeather(). I thought they had no influence on handling POST, since they did not have the Post keyword in them. But they confused it all, and the reason for the problems. So watch out for having more than one handler of a Post in the api controller.
Thanks to Darin Dimitrov, who led me on the right track.
add a method atrribute:
[HttpPost]
public void Post()
{
}
Related
I am trying to build a GitHub application that will handle webhook events and a few other things not related to GitHub. My app has a GitHub controller that should handle all webhook events, but the GH sends all this in one URL.
The way to tell what event we should process is by checking the 'X-GitHub-Event' header value, and I am looking for the most straightforward option to route based on this.
I wouldn't say I like having one #Post() route and using logic inside the method to check the header and call proper service; this way, the controller's method would become huge.
What I am looking for is something like this:
#Controller('github')
public class GitHubController {
#Post()
#GitHubEvent('pull_request')
public processPR() {...}
#Post()
#GitHubEvent('comment')
public processComment() {...}
}
I’m trying to make a POST request via Guzzle to a Yii controller but getting a "Bad Request #400". I thought when I don’t use behaviours() the controller is automatically accessible to all kinds of requests, but nope. How I can solve this? What would be best practice for CURL/Guzzle requests in Yii2?
class ImportController extends yii\web\Controller {
public function actionIndex() {
return 'OK';
}
}
You should create a rest controller instance (yii\rest\ActiveController) and implement authentication for it as described here: https://www.yiiframework.com/doc/guide/2.0/en/rest-authentication
That is probably the correct approach to your use case, and you would not have to deal with CSRF.
I'm upgrading from v3 to v4 of MvcSiteMap, and it seems just using the property Html.MvcSiteMap().SiteMap.CurrentNode.HasChildNodes triggers a hit on HandleUnauthorizedRequest in AuthorizeAttribute for every unathorized child node in the list.
Why should this happen? I would expect HandleUnauthorizedRequest to be triggered for a separate http request, not just interrogating whether a node exists.
What is the best way to distinguish between a 'genuine' unauthorized http request and simply checking an unauthorized sitemap node? My best guess so far is to check whether the controller and action match, but it seems a little unnecessary:
protected override void HandleUnauthorizedRequest(System.Web.Mvc.AuthorizationContext filterContext)
{
if (filterContext.HttpContext.Request.IsAuthenticated)
{
var httpRouteData = ((MvcHandler)filterContext.HttpContext.CurrentHandler).RequestContext.RouteData;
var filterRouteData = filterContext.RequestContext.RouteData;
var isHttpRequestUnauth = (httpRouteData.Values["Controller"] == filterRouteData.Values["Controller"] &&
httpRouteData.Values["Action"] == filterRouteData.Values["Action"]);
if (isHttpRequestUnauth)
throw new System.Web.HttpException(403, string.Format("Access denied for path '{0}'. ", filterContext.HttpContext.Request.RawUrl));
else
base.HandleUnauthorizedRequest(filterContext);
}
else
{
base.HandleUnauthorizedRequest(filterContext);
}
}
HandleUnauthorizedRequest is only called by the MVC AuthorizeAttribute in the case where the authorization check fails. It is meant only for setting the handler of the request, not actually to provide the check whether the user is authorized. That said, MvcSiteMapProvider doesn't call HandleUnauthorizedRequest directly - it calls OnAuthorization.
The default implementation of AuthorizeAttribute.OnAuthorization makes the check already, so I am unsure what you hope to accomplish by comparing the controller and action again in HandleUnauthorizedRequest since unauthorized users cannot reach that path unless you override the implementation of OnAuthorization as well (or you rely on output caching entirely).
Anyway, to answer your question, in v3 and early revisions of v4 MvcSiteMapProvider used Reflection.Emit to generate a class on the fly that inherited from AuthorizeAttribute or any subclass of AuthorizeAttribute as described in this post. The subclass added public access to the AuthorizeCore method so it could be called by MvcSiteMapProvider. However, that approach had performance issues and also could not be used with sealed overloads of AuthorizeAttribute.
Since then, it has evolved to use the one and only public member of AuthorizeAttribute - OnAuthorization - to do the check. The author of the above post made an error in his assertion that Reflection.Emit was the only way it could be done because he didn't take into account using a subclass of HttpContext.Response that overrides the output caching members. We compromised on using the result of HandleUnauthorizedAttribute (setting the filterContext.Result property to a non-null value) as the way to determine whether or not the security check works.
Unfortunately, there is not a way to make a solution that works 100% of the time because AuthorizeAttribute was only designed to be used in the context of a request for the current page, but this is the solution that we compromised on because it requires the least amount of code to maintain, performs the best, and uses direct method calls instead of workarounds. If you use the typical method of overloading AuthorizeCore for custom logic, it will work perfectly. On the other hand, if you overload OnAuthorization or HandleUnauthorizedRequest, you need to ensure that the filterRequest.Result property is set to non-null for unauthorized and null for authorized.
We're having some discussion in our team that all the methods which are returning JsonResult should be moved to WebApi 'controllers' so that there is a clean segregation.
I'm not too sure about that. Is it wrong for a MVC controller to return ActionResults as well as JsonResults?
In our projects, we indeed move the actions for ajax request to a partial controller called "ScriptController" or "WebApiControler".
I think it is good to maintain, codes also seem to clear.
After certain actions (say a PUT or a DELETE) in my services, I will like to send a notification to a user or to a group of users, this is done before send the response of the action.
My way to implement notifications is quite simple, I have an interface:
public Interface INotification{
void send(string mail, string content);
void send(Group group, string content);
}
that represents every type of notification. I inject the types of notifications that are used in a given service but I don't see this as an optimal solution. Is there a better way to accomplish this? are any frameworks that integrates easily with ServiceStack that help me achieve this?
Another problem from my point of view is loading a template, this is done every time I send the notification. I don't like this approach since I assume that this is not optimal. (but this is a different problem)
Thanks for all the help you can provide me.
I am considering adding EventStore to my app to handle a similar scenario, with the added requirement of an auditable history of object changes:
https://github.com/joliver/EventStore
I've not tried it out yet.