Best Practices for Placeholders

[alevine]

I'm looking for any advice on best practices for creating placeholders in the tree that contain things like selectors, or even assets that should be accessible by end users, but not necessarily browseable.

  In my tree, I have a "Selectors" placeholder, underwhich I have various categories of Pages used for selector values.  Should I have this marked as hidden and/or unpublished to keep it from appearing in any brute-force url attempts?  I'm pointing directly to the specific selector tree when defining my fields, but I'm not sure what ramifications the upper selector's visiblity will have.

I guess the underlying question is how are those attributes inherited/passed down to children? I know in my searches I can specify to include hidden pages, but if I start my search underneath will I also need to include that?  Is this behavior explicitly defined, or currently just a "that's the way it is as an artifact of the way things are designed" that may accidently change at some point?

I think a follow up question to this is, how do I best test my site for vulnerabilities/leaked information that's not locked away?

Thanks as always!

[kongondo]

Alevine,

I'm somewhat confused by your approach. I do not understand your scenario  and what you want to achieve. Why would you have your end users have access to selectors? Why not have the selectors  as "normal" - in the template files? Won't page reference fields achieve what you want? I am guessing you are looking to provide choice? Anyway, since am not clear about the situation I can't comment further  

[ryan]

I'm with kongondo, in that I'm confused and not sure I understand exactly what you are talking about. But I'll respond to the nuggets that I did understand.

I guess the underlying question is how are those attributes inherited/passed down to children? I know in my searches I can specify to include hidden pages, but if I start my search underneath will I also need to include that? 

Page status (hidden, locked, unpublished) does not inherit through the tree at all. A status on one page applies to that page only, and says nothing about it's children, etc.

Is this behavior explicitly defined, or currently just a "that's the way it is as an artifact of the way things are designed" that may accidently change at some point?

That behavior is intentional and will not change. 

I think a follow up question to this is, how do I best test my site for vulnerabilities/leaked information that's not locked away?

Your site will only display information that you specifically and intentionally output in your template files. If it is for something that you don't want to display, then it can be as simple as not having a template file at all for pages using a given template. If it's information that you only want to show to some users (like authenticated users with role "members", for instance), then you would perform a check before displaying your confidential information:

if($user->hasRole('members')) {
  echo "<p>Launch codes: {$page->launch_codes}</p>";
} else {
  echo "<p>Sorry, you do not have access to play this game.</p>";
}

[adrian]

I think you're referring to select options (ASM etc) and the page fieldtype and how best to set up and where to store the page tree that contains the options for selecting from? alevine - is that the gist of the first part of your question?

[alevine]

Hah I'm not entirely sure now what I was trying to ask (I was a mushy brain at that point).  I think Ryan best answered, as my concerns were focused on visibility of tree items, and not allowing brute navigation from an end-user's side.  I just need to better wrap my head around content accessibility from the admin and end views.