Pre-authenticated request for Object Storage bucket expires prematurely, blocking automated file uploads

Cloud Platforms Oracle Cloud
, , , , , , , ,
1

I created a pre-authenticated request (PAR) for our Object Storage bucket to allow external partners to upload files. I set the expiration to 7 days from creation, but the PAR stopped working after just 5 days. When partners try to upload, they get an “access denied” error.

Here’s how I created it:

oci os preauth-request create --bucket-name partner-uploads \
  --name "partner-access" --access-type AnyObjectWrite \
  --time-expires "2025-02-15T13:30:00Z"

The current time is February 13th, so it should still be valid for 2 more days. I checked the bucket access logs and see 403 errors starting from February 11th. Is there a timezone issue with PAR expiration times, or could something else be causing early expiration? Our workflow depends on these 7-day windows.

2

Another tip: when creating PARs programmatically, use ISO 8601 format with explicit UTC timezone indicator (the ‘Z’ at the end). Some libraries default to local timezone if you don’t specify. I’ve also seen issues where daylight saving time changes can cause confusion if you’re calculating expiration dates manually.

3

Check what timezone your system was in when you created the PAR. The --time-expires parameter expects UTC time, but if you passed a local time thinking it was UTC, that could explain the 2-day discrepancy. What timezone are you in?

4

Exactly. Always convert to UTC when setting PAR expiration times. I recommend using a command like date -u -d "7 days" +"%Y-%m-%dT%H:%M:%SZ" to generate the correct UTC timestamp. This will calculate 7 days from now in UTC format automatically. Also, the bucket access logs you mentioned are helpful - they should show the exact timestamp when requests started failing, which can help you verify the actual expiration time.

5

While troubleshooting, check if your bucket has any lifecycle policies that might be interfering. Also, verify that the PAR wasn’t revoked accidentally. You can list all PARs with oci os preauth-request list --bucket-name partner-uploads to see the actual expiration time that was set versus what you intended.

6

The issue is definitely timezone-related, and this is a common mistake with OCI Object Storage PARs. Let me clarify all three focus areas:

1. PAR Expiration Time Handling: The --time-expires parameter in OCI CLI strictly expects UTC format (ISO 8601 with ‘Z’ suffix). When you provided 2025-02-15T13:30:00Z, the system interpreted this as UTC time. However, if you calculated this timestamp based on your local Eastern Time (UTC-5), you effectively shortened your PAR lifetime by 5 hours. Over 7 days, this adds up, but the real issue is if you used a local timestamp thinking it was UTC - that would create exactly the 5-day vs 7-day discrepancy you’re seeing.

2. Time Zone Handling Best Practices: Always work in UTC for PAR expiration:

# Generate correct UTC timestamp for 7 days from now
EXPIRY_DATE=$(date -u -d "+7 days" +"%Y-%m-%dT%H:%M:%SZ")
oci os preauth-request create --bucket-name partner-uploads \
  --name "partner-access-$(date +%s)" \
  --access-type AnyObjectWrite \
  --time-expires "$EXPIRY_DATE"

Alternatively, use relative time in your automation:

from datetime import datetime, timedelta
expiry = (datetime.utcnow() + timedelta(days=7)).strftime('%Y-%m-%dT%H:%M:%SZ')

3. Bucket Access Logs Analysis: Your access logs showing 403 errors starting February 11th confirm the PAR expired then. To verify:

# List all PARs to see actual expiration
oci os preauth-request list --bucket-name partner-uploads

# Check specific PAR details
oci os preauth-request get --bucket-name partner-uploads \
  --par-id <your-par-id>

The output will show timeExpires in UTC. Compare this to when 403s started appearing in logs.

Additional Troubleshooting:

  • Enable detailed logging: `oci os bucket update --bucket-name partner-uploads --object-events-enabled true
  • Monitor PAR usage before expiration to plan renewals
  • Consider using bucket lifecycle policies for automatic cleanup
  • For production workflows, create PARs with buffer time (e.g., 7.5 days instead of exactly 7)

Prevention Strategy: Implement a PAR renewal system that checks expiration 24 hours in advance and creates a new PAR with overlapping validity. Store PAR metadata (creation time, expiration, purpose) in a tracking database to avoid timezone confusion.

For your immediate fix: Create a new PAR using the UTC timestamp generation method above, and notify your partners of the new URL. The old PAR cannot be extended once created.

7

We’re in US Eastern Time (UTC-5). I think I see the problem now - I probably used local time instead of UTC when calculating the expiration. So when I thought I was setting February 15th at 1:30 PM, it was actually treating it as UTC which would be 8:30 AM my time?