0

Any ASP.NET WebAPI2 ApiController method names that do NOT begin with a configured METHOD prefix (by default Get..., Post..., Put..., Delete..., Head..., Options..., and Patch...) will match an HTTP 'POST'. (See Is there a default verb applied to a Web API ApiController method? for details.)

I would rather have to opt-in for every method, by convention, than opt-out.

To me, the opt-out approach represents a greater security risk, and has no helpful payoff; for consistency, to support POST the implementer should prefix the class method Post... regardless. For example, an ApiController method named SensitiveFunction() shouldn't match any HTTP METHOD unless I intentionally configure support for a 'SENSITIVE' HTTP METHOD.

Is there a simple configuration change that will allow me to disable this POST fallback policy?

Alternately, am I overlooking some reason I would need this fallback policy?

Community
  • 1
  • 1
shannon
  • 8,664
  • 5
  • 44
  • 74

1 Answers1

0

The default action selection only looks for public instance methods. By making your method public you are effectively "opting in". Scope your methods appropriately with only methods intended to be seen via the API interface as public and everything else private.

http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-and-action-selection

Which methods on the controller are considered "actions"? When selecting an action, the framework only looks at public instance methods on the controller. Also, it excludes "special name" methods (constructors, events, operator overloads, and so forth), and methods inherited from the ApiController class.

Casey
  • 693
  • 7
  • 18
  • As I mentioned in my question, I need to instrument it for additional testing. In this case, the base class provides a method to enable logging for injected context. So, thanks for your suggestion, but it already *is* scoped properly. The "Post" fallback provides nothing other than potential for confusion. Consider: a method that meets no rules now will meet the post rule. Yet, we already have an accepted, standard, rule-based way to engage post: name the method with a Post prefix. For many very clear principles this is just bad form. – shannon Apr 15 '15 at 13:40
  • Also note that, per your quote, methods from the ApiController base class are automatically excluded. Why? Because of the common need to publicly scope members of the controller class for basic implementation. Which is exactly what I've done in my project: derived a new base class for use in my project. It's a very common practice. – shannon Apr 15 '15 at 13:44
  • My question was how to disable this policy; and tangentially, to describe the functional value of it. Your response doesn't address. – shannon Apr 15 '15 at 13:48
  • Whoah, so much anger directed at someone offering help. This issue must be really bugging you. I read you question 3 times, I still can't find the reference to instrumenting it for additional testing. – Casey Apr 15 '15 at 13:53
  • There's no emotion here. Just pointing out that you avoided answering the questions to share incorrect assumptions. – shannon Apr 15 '15 at 14:00
  • It's a very common thing for people new to SO, to not answer the question, refuting its value instead. I've been around here for a while. It doesn't bother me, I'm just pointing out that you should try to answer the question if you post a solution. If you don't want to answer the question, it should go in a comment instead. – shannon Apr 15 '15 at 14:01
  • Lol at your assumptions. – Casey Apr 15 '15 at 14:04
  • You can always derive from apiControllerActionSelector to override the post fallback and swap you derived service in for the default. But that's not a "simple" configuration change – Casey Apr 15 '15 at 14:06
  • If by assumptions, you are referring to "people new to SO", I did not say you are. I'm sorry if it came out that way and it sounded offensive. I haven't looked, but also did not mean to imply. I was explaining my natural reaction to remind people to post something helpful. – shannon Apr 15 '15 at 14:08