Is the super slurper wizard working right now?

I was interested in using Super Slurper to transfer data into an R2 bucket. Unfortunately, I can’t get past the first page of the wizard. It tells me that my credentials are invalid, regardless of what I put in there. I tried my S3 credentials and I just get an error like “Access to bucket denied”. I tried some R2 credentials, and I get "Bad request: R2 source must specify an account for the bucket (Code: 5400) ". But I picked the bucket from a dropdown, so presumably the wizard should know whose account it is.

Is it just me?

What are you copying from - R2 or S3?

  • If it’s from R2 (to R2: between R2 buckets), you do need to enter a valid set of R2 credentials that can access that bucket.
  • If it’s from S3 (to R2: from AWS to Cloudflare), then you need to provide a set of S3 credentials that can read from your S3 bucket.

For example, to copy between R2 buckets, I need to provide credentials for that bucket:

In the next step, when you choose a destination, you will either need to:

  • Re-use the same credentials: which means they need to be able to perform Object Read AND Write to BOTH buckets
  • Create a new set of credentials with Object Read AND Write specific to the destination bucket

In the below I’ve done the latter:

Thanks for the response!

My main quest is to transfer FROM S3. I merely experimented with transferring from R2 to see if the behavior was any different. In both cases, I don’t get past the first step.

S3:

In this case, when I look in the inspector, I can see a POST to connectivity-precheck, and the result that comes back has code 200 and a response like

{
  "result": {
    "connectivityStatus": "error",
    "code": "BucketAccessDenied",
    "reason": "Access to bucket denied"
  },
  "success": true,
  "errors": [],
  "messages": []
}

That obviously looks like I’ve just pasted in bad credentials. But I’ve tried using them with awscli a zillion times with no trouble. I can even see that they’re the same creds I used to set up Sippy since I had a script for that. I’m like 99.99% sure they’re correct at this point. :sweat_smile: Plus, the weird behavior with R2 (below) gives me reason to look for other causes.

R2:

Not critical to my issue, but maybe interesting

Since I was going a bit crazy I decided to experiment with other things. I have creds for R2 that I’ve also double- and triple-checked, so I wanted to see if I could get any further in the wizard with them. But when I try to use them, I get this:

[Screenshot elided since I’m new and can’t post >1 media object. Suffice to say it looks similar to the shot above, except there’s an extra warning at the bottom. The warning echoes the message seen below.]

In this case, the POST to connectivity-precheck returns 400 and the response looks like:

{
  "result": null,
  "success": false,
  "errors": [
    {
      "code": 5400,
      "message": "Bad request: R2 source must specify an account for the bucket"
    }
  ],
  "messages": []
}

So I don’t even know if my credentials are to blame or not!

I’ve tried a couple other things now.

For one thing, I created my own S3 bucket on AWS that I could use as a source bucket. I was able to enter the credentials just fine in the new Sippy UI and get it enabled. So at least I’m doing something right!

Second, I tried Sippy’s new API endpoint, but only got 403s in every circumstance. I tried both sources (the original S3 source credentials that don’t work in the UI, and my new, personal test credentials that do work in the UI) and got the same result:

{"success":false,"errors":[{"code":10000,"message":"Authentication error"}]}
curl: (22) The requested URL returned error: 403

Since the API has changed since I originally set up Sippy, it’s hard to know if I’m really getting it right, but it seems fishy.

Note that my original S3 credentials are still actually being used by Sippy, which I set up via the old API! So even though it really looks like my S3 credentials are just bad, I know this isn’t the case. I can still use them just fine from the aws cli, which confirms it.

Alas, it looks like I can’t edit posts yet because my account is still too new.

But I meant to mention that I have also successfully used my new, personal S3 credentials in the Super Slurper Wizard UI. I have been experimenting with both Sippy and Super Slurper and should really make a table of what works and what doesn’t… I’m out of time for today, but I’ll look at this again on Monday.

This is resolved now. My mistake was assuming that credentials that are able to read the bucket’s contents would be sufficient, rather than following the instructions to the letter. Even though I could use the credentials for listing and downloading objects from awscli, and even though they are currently in use by Sippy, they are nonetheless unusuable with Super Slurper.

I figured this out by asking our partners who own the source bucket to regenerate credentials for me following the instructions at Super Slurper · Cloudflare R2 docs. They worked! :confused: :sweat: :smiley:

So, in the end, it really was something wrong with my credentials, although I don’t know what.

1 Like