Access Control Element

[Christopher McKenzie]

Hello,

Has anyone else given any thought about an access control element that would handle user permissions and respectively hide/show its child elements based on an authorization token of some sort.

perhaps it could look like this: 

<user-restrict accept="admin, user" deny="public, anonymous">
  <menu-item>User Settings</menu-item>
</user-restrict>

I have been working on something like this but was curious if anyone else thinks it might be useful. I am aware of the security issues with access control in js but if it used some sort of constant server checking or a token as said before it might be fairly secure?

Just a thought,

Christopher McKenzie

[Dominic Cooney]

I wonder if this could be applied to UI elements in general using some kind of mixin which interprets attributes like data-accept-role="admin,user" applied to any element. (Custom Elements are nearly done... now we'll do Custom Attributes?)

Once you have "accept" I'm not sure that you also need "deny".

Security related, more prosaic, but probably useful would be a form component which managed an XSRF token.

Dominic

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

[Christopher McKenzie]

I like the idea of a custom attribute! the deny wouldn't be used at the same time it was more just showing that we could have an explicit deny as well. 

As far as implementing the custom attributes (data-attributes) that would not be under the scope of polymer.  Another option would be to implement the access control on a base element that all elements in an app or framework would implement then you could have the attributes sans the data-* prefix, slightly cleaner but a little more of a chore to implement because it would have to added by individual element developers.

[Eric Bidelman]

I experimented with something similar for chromestatus.com. If the user is logged in,

the server renders the feature list markup with a |whitelisted| attribute [src]:

<chromedash-featurelist whitelisted></chromedash-featurelist>

Inside that element, when |whitelisted| is present each feature includes a link to edit it: [src]:

<a href="/admin/features/edit/{{feature.id}}" hidden?="{{!whitelisted}}">edit</a>

That <a> gets distributed into the Shadow DOM of another element, <li is="chromedash-feature">. If <chromedash-feature> sees an element with class="edit come through, it renders it (<content select=".edit">) where it needs to.

What I like about this setup is that 1.) <chromedash-feature> doesn't need to know anything about the user's logged in state. It just renders any light dom nodes it cares about, and 2.) A single |whitelisted| property on <chromedash-featurelist whitelisted>

controls the whole dance.

Don't get me wrong...this is NOT a security feature. One could easily set chromeFeatureList.whitelisted = true in the console and turn on the edit links. The protection comes from the server requiring authentication for the handler.

Anyways, thought this was worth sharing. I'd love to see more exploration in this area.