not authorized auth state for the authenticator about amplify-ui HOT 4 CLOSED

Thank you for the feature request / prospect of a PR! For clarity, can you please provide a snippet of example usage?

from amplify-ui.

the usage should be something like:

withAuthenticator(() => <Comp />, {
//maybe the predicate should be inside a config object, 
  to allow for easy addition of properties in the future 

authorizationPredicate: user => 
    user.signInUserSession.accessToken.payload["cognito:groups"].indexOf('myGroup') >= 0,

children: [
    <Unauthorized slot="unauthorized" message="you should upgrade to see this"/> //optional, will get the user in props
  ]
})

of course you can use this with the Authenticator component directly as well

from amplify-ui.

This kind of protection likely should not happen on the front end, unless you were to include a build step which serializes the predicate and sends it to a secure back-end resource for later use in safeguarding group data. This would be a cool experience, but definitely falls outside of Amplify's scope.

While there is not a front-end component visibility "rule" system surrounding withAuthentication, there are ways to achieve what you're describing. An isAuthenticatedUserMemberOfXGroup hook, for example:

function isAuthenticatedUserMemberOfGroup(groupName: string) {
  const [is, setIs] = useState<boolean | undefined>();
  // get `user`
  // see if the predicate rings true
  setIs(user.signInUserSession.accessToken.payload["cognito:groups"].indexOf(groupName) >= 0);
  return is;
}

function MyComp() {
  const isMemberOfG = isAuthenticatedUserMemberOfGroup("MyGroup");
  return isMemberOfG && (
    <div>Only members of "MyGroup" can see this</div>
  )
}

Bringing these checks into UI component props would likely result in a somewhat rigidly-structured API. It's my sense that this functionality would be best represented in case-by-case specificity.

@sammartinez @wlee221 –– what are your thoughts?

from amplify-ui.

sorry for disappearing.. and thanks for the detailed answer

I don't think there is a security issue here, since the withAuthentication only can block the view of a component. the actual content should be protected on the server side either way.

the code in the Authenticator takes the state it gets from server and according to it decides what to display, I'm just letting me/the user add some logic to that

all that I'm trying to solve here is the client code, which really doesn't care why you can't see something, it only wants to know

1. should it display the content
2. what should it display instead

with current implementation I have nested ifs each of them dealing with a different reason (authentication, authorization, anything else.. ), I thought that doing it all in one place could be nice.

I'm really not attached to the API I suggested, will be glad to hear other ideas :)

from amplify-ui.