This is an interesting one!
I'm not actually able to reproduce the 403 error. It may be possible that 403 indicates you haven't approved the ASF data access EULA in EDL. Be sure that you can manually download the data using your provided credentials.
When I try to download using your provided code, I get a 401 error. Honestly, I'm not at all familiar with rasterio, but after a bunch of troubleshooting with `gdal.SetConfigOption("CPL_CURL_VERBOSE", "YES")`, this appears to be, best as I can tell, an issue with rasterio's gdal interface.
When you access OPERA data from ASF, this is the flow:
When I try to download, no matter what I do, I can't get rasterio+gdal to provide my auth to urs.earthdata.nasa.gov.
If I short circuit the process a bit and start my request at step 3,
Its also worth noting, that this doesn't seem to affect Sentinel-1 data, which follows a similar path, exchanging cumulus.asf.alaska.edu for sentinel1.asf.alaska.edu. I was able to pull (but obviously not read a EDL/URS restricted sentinel product file no problem.
This isn't a workable solution. But its indicative a deeper problem somewhere in the tool chain, one I don't understand very well.
If you can confirm that you are able to manually download the data, and still getting a 403 error using those credentials, I'll try to escalate the issue to the team that manages cumulus.asf.alaska.edu. Given the different behavior between Sentinel products and OPERA products, there may be thread for them to pull.
I'm not actually able to reproduce the 403 error. It may be possible that 403 indicates you haven't approved the ASF data access EULA in EDL. Be sure that you can manually download the data using your provided credentials.
When I try to download using your provided code, I get a 401 error. Honestly, I'm not at all familiar with rasterio, but after a bunch of troubleshooting with `gdal.SetConfigOption("CPL_CURL_VERBOSE", "YES")`, this appears to be, best as I can tell, an issue with rasterio's gdal interface.
When you access OPERA data from ASF, this is the flow:
Code:
1. datapool.asf.alaska.edu ( data location service) -> 2. cumulus.asf.alaska.edu (cloud distribution) -> 3. urs.earthdata.nasa.gov (OAuth2 Service) -> 4. cumulus.asf.alaska.edu ( cloud distribution) -> 5. AWS cloudfront ( S3 out-of-region Distribution )When I try to download, no matter what I do, I can't get rasterio+gdal to provide my auth to urs.earthdata.nasa.gov.
If I short circuit the process a bit and start my request at step 3,
Code:
url = 'https://urs.earthdata.nasa.gov/oauth/authorize?client_id=BO_n7nTIlMljdvU6kRRB3g&response_type=code&redirect_uri=https://cumulus.asf.alaska.edu/login&state=%2FCSLC%2FOPERA-S1%2FOPERA_L2_CSLC-S1%2FOPERA_L2_CSLC-S1_T173-370301-IW1_20160702T134318Z_20240611T083135Z_S1A_VV_v1.1%2FOPERA_L2_CSLC-S1_T173-370301-IW1_20160702T134318Z_20240611T083135Z_S1A_VV_v1.1.h5ds = rio.open(url)Its also worth noting, that this doesn't seem to affect Sentinel-1 data, which follows a similar path, exchanging cumulus.asf.alaska.edu for sentinel1.asf.alaska.edu. I was able to pull (but obviously not read a EDL/URS restricted sentinel product file no problem.
This isn't a workable solution. But its indicative a deeper problem somewhere in the tool chain, one I don't understand very well.
If you can confirm that you are able to manually download the data, and still getting a 403 error using those credentials, I'll try to escalate the issue to the team that manages cumulus.asf.alaska.edu. Given the different behavior between Sentinel products and OPERA products, there may be thread for them to pull.
Statistics: Posted by bbuechle — Tue May 20, 2025 8:43 pm America/New_York