<p>From experience, in terms of ui/ux AND ease in front end stages, If you can do things the other way round, do that.</p>

<p>So attached entries to users basically. When you have a new user, you add entries in one place vs adding the user on every single entries which, if you have loads of could turn into a bit of a mission.. You'll find this way round easier to maintain, in the front end, you can just access related entries through the currentUser very easily instead of going through entries.</p>

<p>This is my personal preference based on recent experience but I don't know how much flexibility you have in terms of development so it may not be possible for you.</p>

CC BY-SA 3.0
2015-11-17T14:21:34.433Z
Thank you for your answer.

I would've thought the opposite from a UX perspective. 

For example, if I wish to assign multiple users to an entry, I can do it in one place (the entry). By doing it the way you've suggested, I would have to assign the entry in each user's profile.

It also means that at a glance in the entries section, there is no way for me to determine who has access to each entry.

I can see your argument from a template perspective however.
Kyle
CC BY-SA 3.0
2015-11-17T15:05:18.827Z
Ha! I guess I don't have your full use case so it depends :)
Oli
CC BY-SA 3.0
2015-11-17T15:29:21.987Z
Yeah, I appreciate that! :)
Kyle
CC BY-SA 3.0
2015-11-16T15:50:15.470Z
2015-11-16T15:50:15.470Z
Oli
<p>I am looking to implement a website where access to pages <em>and</em> their related pages is restricted to certain users.</p>

<p>How I thought it might work is that a user (or users) would be assigned to the entry. This user should then have front end access to this entry <em>and its related entries</em>.</p>

<p>So, the template would check the currentUser value against the user in the entry, and also against the relatedTo entries. </p>

<p>Is there a better, more efficient way? I feel this may suffer from performance problems as the number of related entries grows. Any advice or guidance would be greatly appreciated! </p>

<frontend><templating><authentication>
Front end authentication on an entry and its related entries
# Front end authentication on an entry and its related entries

(Asked by: username_0 on 2015-11-16)

I am looking to implement a website where access to pages *and* their related pages is restricted to certain users.

How I thought it might work is that a user (or users) would be assigned to the entry. This user should then have front end access to this entry *and its related entries*.

So, the template would check the currentUser value against the user in the entry, and also against the relatedTo entries.

Is there a better, more efficient way? I feel this may suffer from performance problems as the number of related entries grows. Any advice or guidance would be greatly appreciated!

**Tags:** frontend, templating, authentication


---

## 1 answers

### Answer by username_1 on 2015-11-16. Score: 2 | Accepted answer

From experience, in terms of ui/ux AND ease in front end stages, If you can do things the other way round, do that.

So attached entries to users basically. When you have a new user, you add entries in one place vs adding the user on every single entries which, if you have loads of could turn into a bit of a mission.. You'll find this way round easier to maintain, in the front end, you can just access related entries through the currentUser very easily instead of going through entries.

This is my personal preference based on recent experience but I don't know how much flexibility you have in terms of development so it may not be possible for you.

> **Comments:**
> **username_0**: Thank you for your answer.  I would've thought the opposite from a UX perspective.   For example, if I wish to assign multiple users to an entry, I can do it in one place (the entry). By doing it the way you've suggested, I would have to assign the entry in each user's profile.  It also means that at a glance in the entries section, there is no way for me to determine who has access to each entry.  I can see your argument from a template perspective however.  
> **username_1**: Ha! I guess I don't have your full use case so it depends :)  
> **username_0**: Yeah, I appreciate that! :)  

---

