AllowAnonymous doesn't work about hawknet HOT 3 CLOSED

Yes, that's true. However, I am not sure there is possible to put a quick fix for that. If the client does not send an authorization header, the Hawk filter must return a challenge. The check about AllowAnonymous is performed later in the pipeline. The message handler does not even have access to the api method via reflection to get those attributes. What you can do is to configure the HawkMessagehandler for certain routes as I did here in this post,

http://weblogs.asp.net/cibrax/archive/2013/02/25/message-handlers-per-route-in-asp-net-web-api.aspx

I will remove that example with AllowAnonymous as it is broken as you said.

Thanks
Pablo.

from hawknet.

Well, actually, after I posted the above I started to dig a bit more and found a way to solve (at least on my project, but it should work on this too). Basically, what I'm doing is the following:

1. In the SendAsync method, I first check if I have an Authorization header and if Scheme matches my scheme. If so, goto 2 else goto 3 :)
2. Get a principal based on the request headers (here it is up to the implementation)
3. return a base.SendAsync, but use a continuation (ContinueWith) and check if the result.StatusCode of the continuation is Unauthorized and if the Authorization is null or the Scheme is null or empty. In that case, send the challenge.

So later, the Authorize attribute on the action will check for an authorized principal and if it is not, it will return an Unauthorized response that will be catch'ed by the continuation.

I already have that implemented and it seems to be working fine.

from hawknet.

I found a way to fix this issue. The challenge is only returned when the upper layer returns Unauthorized. It's in the latest version. Thanks

from hawknet.