latest stable versions: v150827 (changelog)

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

CloudFront Err 400: Unable to del existing…

Home Forums Community Forum CloudFront Err 400: Unable to del existing…

This topic contains 5 replies, has 4 voices. Last updated by  Cristián Lávaque 4 years, 7 months ago.

Topic Author Topic
Posted: Wednesday Jun 6th, 2012 at 9:26 am #15684
Eran
Username: sheriff

Error code: 400. Error Message: Unable to delete existing Amazon® CloudFront Origin Access Identity. Unable to delete existing Amazon® CloudFront Origin Access Identity. Bad Request

I set up and tested Amazon S3 bucket – works fine.

Having trouble setting CloudFront:
1. Set up CloudFront keypair ID and Private key, checked s2member automatically configure my Amazon… Configuration reported success. Tested download and got an error.
2. Suspecting that was due to using wrong private key, I deleted existing key and regenerated a new one.
3. In order to start afresh, I also manually deleted all CloudFront distros (in case the issue had to do with distro config).
4. Checked s2member “automatically configure my Amazon”… and pressed save changes. This produced the above error 400 report, and at the same time a message: “Your Amazon® CloudFront Distributions are: ( ALREADY configured! )”. This is obviously incorrect as I manually deleted all distributions.

I’m assuming s2member’s keeps track of current setup and may “confused” as it shows a distribution exists, while I manually removed all distributions (the one set by s2member and others I set myself for other purposes). I tried removing/re-entring the keypair ID and private key and nothing worked.

Is there a way to reset s2member to start afresh? Alternatively, somehow make it realize there are no distros so no need to delete anything before setting a new s2member distrto? Perhaps the issue is elsewhere.

Followed other threads with similar issues, but couldn’t find answers which seemed pertaining to the case at hand. The one potentially relevant post is: http://www.s2member.com/forums/topic/unable-to-auto-configure-amazon-cloudfront/#post-11763

Please advise. Many Thanks…

Addenda (some thoughts which may help):
1. Tried checking the suggestions given in the post referenced above – didn’t work.

2. Saved the configuration and inspected the file. Seems that some of the CloudFront stuff isn’t cleared. I’m contemplating clearing it manually then reloading the config file. There are two potential issues with that:
a. Unclear that removing the setup strings is all it takes – there can be other parameters which are excluded from the config file.
b. Unclear that I correctly identified the relevant fields. It seems straightforward, but can’t be sure.
Consequently by doing so I may screw up the entire setup.

3. The above seems to indicate a need for additional logic: Since users may modify the setup on Amazon manually (or there can be some glitch), it would make sense to add code to verify the setup on Amazon and adjust s2member accordingly. Right now it seems that s2member believes there’s a CloudFront distro it needs to delete, before reconfiguring, while I’ve manually removed all distros.

Please advise. Let me know if the config file idea may work, or else, some other way to resolve this… Thanks again.

  • This topic was modified 4 years, 7 months ago by  Eran.

List Of Topic Replies

Viewing 5 replies - 1 through 5 (of 5 total)
Author Replies
Author Replies
Posted: Thursday Jun 7th, 2012 at 11:02 am #15796
Raam Dev
Username: Raam
Staff Member

Hi Eran,

When you removed the distros over at CF, did you clear out all the fields in s2Member for the integration and save that, before adding a new integration? s2Member shouldn’t be confused about distros already existing if the integration fields are empty, but I’d try clearing out the integration first and starting from zero.

As a last restort test, you could always try installing another copy of WordPress in a sub-directory, installing s2Member, and then try configuring CloudFront again.

Posted: Thursday Jun 7th, 2012 at 12:22 pm #15800
Eran
Username: sheriff

Thanks Raam for the quick response.

To answer your question: yes – I did clear the CF fields in s2member. Also tried inputting the new key. Regardless of whether the fields are empty or full the configuration fails. Played with it for quite a while with and nothing really worked.

I’ve been thinking of doing something similar to what you suggested: Having confirmed that s2member is stable on my development site, I’ve been contemplating using the live site to configure CF, then turning s2member off on the live site till I’m ready to deploy.

While that’s an option, I’d rather keep away from the live site till I’m ready to deploy. This leaves your suggestion as a viable option and if left with no other choice perhaps I’ll do that. What do you think about editing the config file should that work? If so, that would be simpler than installing another instance of WP…

Many thanks

Posted: Thursday Jun 7th, 2012 at 10:20 pm #15884
Staff Member
If you’d like to perform a full reset of everything s2Member stores for a previous Amazon S3/CloudFront integration, please follow these instructions.

Create this directory and file:
/wp-content/mu-plugins/s2-hacks.php
( these are MUST USE plugins, see: http://codex.wordpress.org/Must_Use_Plugins )

<?php
add_action('wp_loaded', 's2_reset_aws');
function s2_reset_aws()
	{
		if(!empty($_GET&#91;'reset_aws'&#93;))
			{
				c_ws_plugin__s2member_menu_pages::update_all_options(
					array(
					     'ws_plugin__s2member_amazon_s3_files_bucket'                     => '',
					     'ws_plugin__s2member_amazon_s3_files_access_key'                 => '',
					     'ws_plugin__s2member_amazon_s3_files_secret_key'                 => '',

					     'ws_plugin__s2member_amazon_cf_files_private_key'                => '',
					     'ws_plugin__s2member_amazon_cf_files_private_key_id'             => '',
					     'ws_plugin__s2member_amazon_cf_files_distros_access_id'          => '',
					     'ws_plugin__s2member_amazon_cf_files_distros_s3_access_id'       => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_downloads_id'        => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_downloads_cname'     => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_downloads_dname'     => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_streaming_id'        => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_streaming_cname'     => '',
					     'ws_plugin__s2member_amazon_cf_files_distro_streaming_dname'     => '',
					     'ws_plugin__s2member_amazon_cf_files_distros_auto_config_status' => ''
					), TRUE, FALSE, FALSE
				);
				exit('s2 Amazon integration completely wiped clean.');
			}
	}

Now visit this page in your browser:

http://yoursite.com/?reset_aws=yes

Then delete the s2-hacks.php file and re-configure Amazon® S3/CloudFront.


Regarding 400 Bad Request errors…

4. Checked s2member “automatically configure my Amazon”… and pressed save changes. This produced the above error 400 report, and at the same time a message: “Your Amazon® CloudFront Distributions are: ( ALREADY configured! )”. This is obviously incorrect as I manually deleted all distributions.

I’m assuming s2member’s keeps track of current setup and may “confused” as it shows a distribution exists, while I manually removed all distributions (the one set by s2member and others I set myself for other purposes). I tried removing/re-entring the keypair ID and private key and nothing worked.

The 400 Bad Request error is very interesting to me. This should NOT be happening obviously, so if it all possible, I’d like to have a look at your installation, to find out why this might be occurring on your installation. If s2Member was previously integrated with Amazon® S3/CloudFront (even if you clear all of the UI option fields), it still makes an attempt to delete the previous configuration, before it is integrated again. However, that attempt should NOT fail with a 400 Bad Request error. If anything, s2Member should simply detect that your Distros and/or Origin Access Identity no longer exists, and simply bypass this routine. The fact that you’re seeing a 400 Bad Request at all, would indicate to me there is something else going on.

Note, there was an issue identified in a previous release, which caused some 400 Bad Request errors, and it was corrected in the release of s2Member v120309.

What version are you running please?

See also: s2Member® Unified Changelog » v120309

If possible, please feel free to submit a Dashboard login and FTP details. I’ll be happy to run diagnostics for you.
See: s2Member® » Private Contact Form

Posted: Sunday Jun 10th, 2012 at 6:06 am #16109
Eran
Username: sheriff

Hi Guys,
Firstly, thanks much for your quick and helpful input.
In the meantime, I found a solution (a kluge, actually): pasting the CF part of a config file saved from a fresh (yet not-configured) s2member installation into the saved config file of the site that had issues, then reloading that hacked config back into that installation.

The above kluge persuaded s2member that CF wasn’t configured, which allowed a fresh configuration (already tested to work well). Naturally, your suggestion is much cleaner. Saved it for future reference (hopefully unneeded).

I’m happy to help and will be in touch through a private communication regarding your request.

Thanks again…

Posted: Monday Jun 11th, 2012 at 11:42 pm #16192

I’m glad you got it working. Thanks for the update. :)

Viewing 5 replies - 1 through 5 (of 5 total)

This topic is closed to new replies. Topics with no replies for 2 weeks are closed automatically.

Old Forums (READ-ONLY): The community now lives at WP Sharks™. If you have an s2Member® Pro question, please use our new Support System.

Contacting s2Member: Please use our Support Center for bug reports, pre-sale questions & technical assistance.