Unable to specify X-Roles wadl:param when rax:roles enabled

[Amelia-Lopez]

I have an existing WADL that already uses rax:roles, and now I need to further restrict some of the URIs by requiring multiple roles. That is, I need to only allow users that have both the roles "Racker" and "XYZ" (where "XYZ" is some API specific role) on a resource that previously only required users to have the "XYZ" role.

Since rax:roles doesn't support requiring multiple roles (i.e. "AND"), I will have to update these resources from using the rax:roles attribute to using a <wadl:param .../> element so I can require both values. This part is fine.

<wadl:param name="X-ROLES" style="header" rax:code="403" rax:anyMatch="false"
    rax:message="You are forbidden to perform the operation" type="xsd:string"
    required="true" repeating="true" fixed="ROLE_1">
<wadl:param name="X-ROLES" style="header" rax:code="403" rax:anyMatch="false"
    rax:message="You are forbidden to perform the operation" type="xsd:string"
    required="true" repeating="true" fixed="ROLE_2">

Ideally, I would like to update only the resources that now require the two roles to use a <wadl:param .../>, but the current rax:roles limitation forces me to completely abandon rax:roles and update all of them to a <wadl:param .../>. Is there a workaround for this?

[RackerWilliams]

I'll look at removing the restriction that you can't use X-ROLES. The issue is that specifing X-ROLES really messes with RAX-ROLES mask.

I think the options are:

1. Only restrict when there is a truly incompatible X-ROLES parameter AND you are masking data.
2. Give a warning that RAX-ROLES mask won't be effective for all cases and let you specify the parameter anyway.
3. Make rax-roles maks work in all cases -- I'm thinking this one will be a challenge.

[RackerWilliams]

This becomes a bit more interesting with capture header extension in the mix.