michaelryanmcneill

You would need to add that outside of the BEGIN Shibboleth and END Shibboleth lines, as the plugin could potentially overwrite those parameters if you added them within the plugin. You could disable .htaccess insertion entirely by adding the SHIBBOLETH_DISALLOW_FILE_MODS constant.

Per the conversation here: https://github.com/michaelryanmcneill/shibboleth/issues/61, I’m marking this issue as resolved as there has been no additional follow up from the user. If there is additional assistance needed, please reopen the issue.

I agree with @jrchamp. Please verify the proper directives are included in .htaccess, as well as that the environment variables are coming through with the proper prefixes. Please update this post with additional information on the status of this issue.

This uses PHP’s error_log() function. It logs directly to the PHP error log, which is supported anywhere that PHP runs. I hope that helps to clarify.

This isn’t really a plugin question. If you’ve got your site entirely protected by Shibboleth, you can modify your Apache configuration to allow the crawler to access the site. If you’re protecting the entire site using WordPress, then you’d need to either configure a service account for the crawler to use, or you’d need to hook into Core and make changes for that specific IP (I’d highly advise against that). Either way, this is a question that is outside of the scope of the plugin.

That likely means one of two things:

1) You’ve not configured Apache properly for Shibboleth authentication and Apache is failing to set the proper environment variables. This is likely caused by your environment not allowing the processing of .htaccess files via the AllowOverride Apache directive: https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride
OR
2) You’ve not configured the plugin for your environment properly. I would say this is a low likelihood.

If you have AllowOverride All set in your <Directory> stanza in the Apache configuration, then let me know and we can do further debugging.

Thanks so much for the review!

Thank you for reporting this issue. Can you please cross post your issue to GitHub?

Per the conversation here: https://github.com/michaelryanmcneill/shibboleth/issues/32, this issue appears to be resolved. Marking it as such here.

Thank you for reporting this issue. I’m not experiencing this issue and am running 2.0.2 on production sites. I’m confused where that code that you are supplying is coming from? Please provide additional information, and also can you please cross post your issue to GitHub?

There are many reasons for the redirect loop, many of which have nothing to do with the plugin. Are you sure that you’re plugin is configured properly for your environment?

This was resolved with the release of version 2.0.1. You can see the full discussion on GitHub here: https://github.com/michaelryanmcneill/shibboleth/issues/22

Thanks for bringing this to my attention. I’m investigating this issue and will get back to you shortly. Can you please cross-post your issue to GitHub?

This plugin adds an additional WordPress authentication method (or optionally replaces the default WordPress authentication method). It does not protect content or restrict the access to content. To accomplish this, you could use a combination of the Shibboleth plugin and a plugin similar to Restrict Content.

Per the GitHub issue, this issue was unrelated to the plugin and has been resolved.