https://discord.cloudflare.com logo
Join Discord
Powered by
# r2
  • v
    As like a default value unconditionally? Is that what S3 does?
  • v
    @Erisa | Support Engineer / @Jaex the sigv4 thing should be fixed. Can you confirm that stock sharex now works?
  • e
    tada

    https://r2-test.erisa.workers.dev/Discord_ymAP8uWin1.png▾

  • e
    works a treat!
  • e
    For reference to others, for ShareX native S3 support I have these settings:

    https://cdn.erisa.uk/bLXT1wEKT4.png▾

  • k
    if someone uses the s3 api, does it go through a worker and count as a worker request?
  • e
    no
  • k
    noice
  • e
    one caveat though - you cant currently read files back from the S3 api without auth, so you need a Worker to serve the files publicly
  • k
    assumably wouldn't be the same by the time ga happens
  • e
    unsure, would have to ask one of the team for that
  • s
    not familiar with S3 API, but sending a PUT request to my r2 endpoint creates a bucket for me, wondering if it's working as intended?
  • i
    I believe they said not by open beta but by GA.
  • e
    You're sending a PUT to /testbucket which would tell it to create a bucket, so I don't see why that wouldnt be normal
  • e
    To upload a file you'd do /testbucket/filename.etc
  • e
    You definitely can create buckets by PUTing them in S3
  • j
    s3 launched before cors or native-app-like-webapps were things
  • i
    On S3 you have to opt-in to CORS via the CORS policy on the bucket.
  • i
  • l
    Ok, It's not working.... Code is public https://github.com/lmtr0/r2-test can someone help me?
  • v
    I'm not super familiar with CORS. So 
    Access-Control-Allow-Headers: *
    fails open or closed?
  • i
    Access-Control-Allow-Headers: *
    says that a fetch request from any site can access stuff.
  • l
    btw does the cloudflare api allow 
    <bucket>.<account>.cloudflare.....
    ? if not, then I found the problem....
  • s
    oh nice, not familiar with S3 api. was wondering why i was uploading a keyless object to s3 using that method
  • i
    If you try to send a request and that's not present on the OPTIONS response (preflight, it's called) the browser refuses to send further requests.
  • i
    So it goes: - Browser sends OPTIONS (preflight) - Server returns 
    Access-Control-Allow-Origin: *
    if it allows any site to be able to do requests - Browser sends actual request (GET/POST/PUT/etc) - Server returns 
    Access-Control-Allow-Origin: *
    to indicate that the browser is allowed to read the response.
  • i
    * is most permissive, if you know who is going to be calling the site you can specify a domain like 
    example.com
    which means that only requests from the 
    example.com
    Javascript are allowed.
  • j
    my suggestion would be to enable fetch requests from any domain for every s3 api call except GET/HEAD object (those should be settable by the user for each object)
  • i
    Should be origin there, not headers, by the way. EDIT: Actually, it should be both, 
    Access-Control-Allow-Headers: *
    to allow amz- headers and 
    Access-Control-Allow-Origin: *
    to allow all origins.
  • i
    Access-Control-Allow-Origin: *
1...767778...1050Latest