Replies: 8 comments 2 replies
-
@jameskleeh can you comment in this issue? |
Beta Was this translation helpful? Give feedback.
-
Likely related issue: #689. I opened that issue because the body was present at that stage in the 2.4.x line and I couldn't find any justification for the change of behavior in the docs; therefore, I considered it was a bug. If it's not, an explanation would be appreciated. |
Beta Was this translation helpful? Give feedback.
-
This could be done via a constraint or AOP. A constraint makes more sense to me from a logical perspective, but if you want a custom response AOP might make that easier since you can throw a custom exception. |
Beta Was this translation helpful? Give feedback.
-
This bit me today upgrading a project from 2.4.x to 2.5.x. My scenario is an app receiving requests from machine clients so each request is individually authorised by a signature in a header. Thanks! |
Beta Was this translation helpful? Give feedback.
-
Garry - I’ll put together an example for you
…On Wed, Jul 28, 2021 at 6:17 AM Garry Turkington ***@***.***> wrote:
This bit me today upgrading a project from 2.4.x to 2.5.x. My scenario is
an app receiving requests from machine clients so each request is
individually authorised by a signature in a header.
To calculate that signature requires fields from the body so we have a few
SecurityRules in sequence that currently implement this. It isn't clear to
me from the above discussions what the idiomatic way to handle this
scenario would be - looks like SecurityRules post 2.5.x are completely off
the table now.
Obviously I'd rather do this validation before my controller methods are
invoked so would really rather not have to rework those to explicitly
include this validation logic. But in the absence of authenticated users
I'm not sure what the best approach for per-request signature body
validation looks like?
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#649 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMCVLPX4TXFWVQYBGGHME3TZ7KKXANCNFSM444NRARQ>
.
|
Beta Was this translation helpful? Give feedback.
-
Thanks James - any pointers would be gratefully received! |
Beta Was this translation helpful? Give feedback.
-
I've created a PR with an example: #756 It is similar to @tcrespog suggestion. |
Beta Was this translation helpful? Give feedback.
-
Thanks to @tcrespog and @sdelamo for the pointers. Transformed my rule into an interceptor and it works fine. Much appreciated, hugely useful! |
Beta Was this translation helpful? Give feedback.
-
Hey there, I have a question about accessing the request body.
We have to integrate with a 3rd party service's webhooks that uses a quite unusual signing method for its requests. Long story short: we have to read the request's body as a string to be able to check the signature they provide in a dedicated header. Before Micronaut 2.5.x we used a custom AuthenticationFetcher implementation, something like this:
This solution worked without any problem, and we could use the
@Secured
annotation with the custom role in our controllers.However, in Micronaut 2.5.x it won't work, because
request.body
is always an emptyOptional
. I understand that this is the desired behavior, but I'm also curious if there is an idiomatic way to achieve the original behavior?After the upgrade we've refactored our logic, and we are just bypassing the built-in security checks by providing
@Secured("isAnonymous()")
to the controller methods and checking the body inside these methods:While this approach also works, it seems a bit strange and "hackish" :(
Beta Was this translation helpful? Give feedback.
All reactions