Handling private pages/posts

[szul]

Changes were made to allow Shibboleth to handle pages and posts that are marked as private, rather than relying on Location or LocationMatch directives in the Apache configuration. Some admins require that subscribers can view private pages/posts, so this allows landing on such pages to redirect to the Shibboleth initiator URL.

[jrchamp]

This is interesting, but I found it confusing. It would be better documented as "If a user is not logged in and tries to access a private page or post, redirect them to the shibboleth login." It was very scary to read "If set, this will cause all private pages and posts to be accessible to subscribers if they are logged in via Shibboleth." We would never want such a thing to be true for our sites, because most of our users only have the ability to comment on articles, not see private information.

It would be nice if you could use the $post or perhaps the wp_query object instead of using _SERVER['REQUEST_URI']. Also, because you're not modifying the permission model, I don't see why you're limiting it to pages and posts. All post types or a customizable set of post types seems like a better strategy for a general-use plugin like this.

[szul]

The design choices are admittedly for our particular use case. I'll make it a little more generic for you and commit it.

[szul]

I changed the documentation to reflect more generic copy.

I was unable to use $post or $wp_query as this function is hooked in wp_header, and those global variables don't seem to be available at that point. Let me know if you have better luck. I needed to use a hook that occurred before WordPress read the post status and redirected unauthenticated users to a 404 message. Unfortunately, "init" occurs after this.

I added the post types of attachment and revision. I left menu nav out, as it doesn't seem to be conducive for this functionality. Ideally, there should be an option in the admin for the user to select the post types (including custom), but that is, unfortunately, beyond the scope of what my institution requires, so they are having me move onto something else. If I have spare time on my own, I'll see what I can do.

Our use case is as follows (which is why this functionality was important):

Pages and posts need to be able to be public or private. Private posts need to sit behind Shibboleth, but stakeholder usage for specifying private posts is with the "private" status. We could not rely on Location or LocationMatch in the Apache configuration, so we needed to hook into WordPress to redirect ourselves. Since we were using this Shibboleth plugin, it was decided that the source would be forked, and then contributed back for other institutions to use.

[szul]

"Also, because you're not modifying the permission model, I don't see why you're limiting it to pages and posts. All post types or a customizable set of post types seems like a better strategy for a general-use plugin like this."

Made this an option in the admin. If the option is not specified, it'll default to all post types. Right now it uses a comma delimited list (with the admin option showing the list of current post types), but ideally, this could be a checkbox group in the future.

Note: The last commit cleaned up some line space/line break issues--difference in editing with vim versus the Atom Editor, I guess.

[szul]

Closing since it's been over two years without comments from the repo maintainer. Will keep the repo in my account active.

[jrchamp]

So I don't forget, in case someone wants to take a look at this:

• Remove whitespace differences so you can see the important part of the diff: https://github.com/mitcho/shibboleth/pull/14/files?w=1
• Move the shibboleth_private_posttypes cleanup to the save function
• Initialize $target in the redirect function with site_url() in case WordPress is in a subfolder
• Compare using get_path_by_page() with something like if ( is_single() ) { $post = get_post(); } perhaps those functions are only available after output has started?