Crossdomain.xml

I read a lot of posts regarding the problem creating crossdomain.xml in S3. I’m having the same problem. The content of the corrupted crossdomain.xml indicates there’s a bug in utilities.inc.php. Here’s what the file contains:

<br />
<b>Parse error</b>:  syntax error, unexpected T_STRING in <b>/home/xxxxxxx/public_html/wp-content/plugins/s2member/includes/classes/utilities.inc.php(46) : eval()'d code</b> on line <b>6</b><br />

Was the S3 integration working fine before and then stopped, or it hasn’t worked for you yet?

Have you tried resetting the integration and creating it again? Knowledge Base » Reset the Amazon S3/CloudFront integration

Also, please use this to verify that everything’s fine with your s2Member installation: Knowledge Base » s2Member® Server Scanner

I have everything working fine now. I created my own crossdomain.xml file to replace the corrupt one s2Member creates. I spent a good half day troubleshooting the autoconfig process. The instructions for resetting the Amazon S3/Cloudfront Integration are good from the plugin perspective, but they don’t go far enough to solve the issues people are having.

After resetting the integration details as per the instructions, I began receiving 400 errors – many different types of 400 errors – when I tried running the autoconfig again. To solve these 400 errors, everything, and I mean everything, s2Member created in S3/Cloudfront needs to deleted before autoconfig will work properly again. It appears that s2Member needs a clean S3/Cloudfront environment to work properly.

In the S3 management console, you have to delete the Grantee created by s2Member and bucket policy for the bucket you’re configuring.

On the CloudFront Management Console, you have to delete the original streams and origin access identities created by previous s2Member autoconfig attempts.

Once you’ve run the s2Member reset and cleaned up the S3/CloudFront side of things, s2Member autoconfig runs smoothly again without error. It still produces the same corrupt crossdomain.xml file as shown in the original post.

The s2-member-server-scanner app shows a perfect score on my server. Green check marks all the way down the page. Creation of the corrupt crossdomain.xml file does not appear to be a server related issue.

Oh yes, and by the way, it appears that Amazon is deprecating access to the secret access keys. The current IAM Management Console does not allow for their retrieval, but displays this message instead:

Note: If you must retrieve existing secret access keys, use the legacy Security Credentials page and save your keys in a safe place. AWS will support the legacy Security Credentials page for a limited time to help during your transition.

Help during your transition? Transition to what?

Thanks for your update, Victor. I’m glad you sorted it out. :)

Just to make sure it isn’t something caused by a conflicting plugin in your setup, could you please test in a separate, clean WP installation (so you don’t modify the one you got working now), with just s2Member, if you have the same trouble with the XML file? Thanks!

I’ll forward your feedback to Jason so he can look into this.

Jason reviewed the Amazon key thing and found that although it looks like it’ll be phased out, their API still requires it, so s2Member will keep working the same way. He added a note to the s2Member to help find the key in its new location.

About the XML file, he found it had a problem and fixed it.

He released an update today: s2Member® Unified Changelog » v130617

Thank you very much for your help sorting these out! :)