Permissions in Templates, Rules and Components

Hi all,

What is a good way to test for permissions in ember? In templates, components or controllers there are no problems. Here I can use an IF condition to render my snippet or execute code by set permissions etc…

But what is the best way to use permissions for routes?

For example:

  • The main navigation will rendered in the application template.
  • The token request and the request for my loggedin user and his permissions is asyncrone and will be solved after get the authentication token

I search for a solution what the best way is to test for permissions on routes until the user request is finished to get the permissions.You know what I mean?

Greeings Mario

You can protect routes like this:

Hi broerse,

I already use an mixin for my route but the problem is the logic inside the mixin. In bas case of an slow request I know my permissions seconds later then the beforeModel or model of the related route is executed and the template is rendered.

We use the default ember-simple-auth mixin and it works perfect. Perhaps take a look a how they do it? I have never wrote my own.

So you need to be sure that first thing you know are permissions, how your mixin looks like ? Maybe in beforeModel return Promise thet resolves after permissions are known.

Thanks for all tipps … I could solve our problem. :slight_smile:

@broerse Similar to the ember-simple-auth addon we had written our own session service that handle the authentication and tokens. Also we have a mixin “authenticated-route” that we need for needed authenticate routes.

@CezaryH My solution is embedded in our “authenticated-route” mixin. In first step the mixin check whether the session is authenticated by set token etc… For the permission check I implemented a “dynamic route permission check” based on the route-name. In beforeEach I get the agent with all permissions within a promise. here I check whether the agent have a permission like the route-name. So we have a possibility to check all authenticated routes without specific implementation for each related route. Finalized this feature is toggled by an environment configuration property so that a specific implementation is possible if needed.

For example: An authenticated route “delivery-info” will check for permission “DELIVERYINFO”. Is the check ok the chain will be called by

return this._super(...arguments);

Best regards, Mario

1 Like