If `checkA` fails an `AuthorizationFailedRejection` will be gathered up.
If `checkB` then succeeds it needs to cancel the `AuthorizationFailedRejection` that was produced earlier, since now the request has indeed been authorised successfully.
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to spray...@googlegroups.com
Mathias,
What about the following scenario?
get { authorize(true) { authorize(false) { ... } } }
In this case, I'd expect the request to be rejected with an `AuthorizationFailedRejection` but the successful outer `authorize` cancels the rejection from the inner `authorize`.
To make this a bit less hypothetical, I ran into this issue by having some independent routes, each using their own fine-grained `authorize` checks, that were later composed together and wrapped with an outer route guarded by a single coarse-grained `authorize` check. Using the default rejection handler, I was surprised to see `404 Not Found` responses when a request was rejected due to an `authorize` failure in one of the wrapped routes.
I went as far as attempting a PR to fix the issue, but I wasn't sure how to satisfy both the constraint that successful `authorize` checks cancel rejections from any sibling `authorize` failures (your example) while also permitting rejections from descendant `authorize` directives to persist (my example).
There is also the possibility I'm just doing it wrong. Nesting `authorize` directives seems to me like reasonable usage, but is there a better way to go about this that I've overlooked?
Cheers,
Emrys
Akos Vandra
unread,
May 29, 2016, 4:50:14 PM5/29/16
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to spray.io User List
Hello,
I just stumbled into this.
This email thread explains why the cancel rejection transformation is there, however I wonder if there is an actual solution to the nested authorize routes, as portrayed by Drew (I have the exact same use-case).