I have run amember 3.x for more than a year with a secure podcast feed using htpassword protection. I launched a new site on a different domain with 4.x installed and using the wordpress integration to protect only portions of the site. I set up my feed folder and used htpassword to protect the xml feed files within. Now however iTunes cannot find those feeds because it is encountering a 301 redirect. If I embed user and password information into the feed url I can then access the content. This is dangerous though because then the username and password is visible in the url. As best I can figure some method of protection within the site that would normally redirect an unauthorized user from a protected page to an error message or redirected url is throwing iTunes into a loop. I have not set any 301s up for this site at all but I can see that this coding is built in to the wordpress integration when I protect pages and/or categories. Trying to visit the url directly through a browser sends me to a 404 page and no request for user and password greets me. Any ideas on the problem here?
Are you sure that the problem is wordpress plugin? Did you tested it with wordpress plugin being disabled? It's not protect feed itself. It just remove protected posts from feed, so it still should work without a problem.
This query is different from my other post. In this example I'm talking about a manually created RSS xml file that has been place into a folder sitting on the root. I think I have a fix and it rests within the htaccess file that amember creates with protection is set on this folder. It presents a potential bug within amember that you guys need to be aware of. Previously when I wanted to protect my entire domain, amember took care of this outside of wordpress so standar wordpress rules didn't apply. Now that I'm protecting content from inside wordpress by using the plugin, these rules are back in play. In this instance iTunes is requesting the url for the xml feed doc. What's happening is the request comes in, hits the auth on the feeds folder that I set up in amember, jumps up the root, and then forwards the request into wordpress. Wordpress doesn't know what to do with that url, so it sends back a Wordpress 404 page. The fix I came up with works by giving the request someplace to go other than wordpress' catchall. Basically, you have to add this to the top of the .htaccess file in the feeds directory: ErrorDocument 401 /feeds/401.html And add a basic 401.html into the folder. Now those requests don't get sent into Wordpress at all. So the plugin isn't really causing the problem but because the domain is partially open instead of fully protected and Wordpress is at the root this 301 issue comes into play. Am I reading this right? Shouldn't amember take this in to account when creating the .htaccess file?
Yes you are correct. But this can't be added to aMember, because this is configuration issue(depends on your site configuration).