Storage Emulator missing auth from IOS SDK

[TRIMER]

It's possible bug in emulators. I can't write secure rules for Storage using 'request.auth'.

[REQUIRED] Environment info

firebase-tools: 9.16.0
platform: macOS
iOS SDKs:

• FirebaseFirestore 8.1.0
• FirebaseStorage 8.1.0
• FirebaseAuth 8.1.0

[REQUIRED] Steps to reproduce

1. Add secure rules to 'storage.rules'.

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /users/{userId}/{allPaths=**} {
      allow read, create: if request.auth != null;
      allow update, delete: if false;
    }
  }
}

2. Run emulators.
3. Run iOS app with code:

Preparing:

// Configure app
let name = "TestApp"
FirebaseApp.configure(name: name, options: .defaultOptions()!)
let app = FirebaseApp.app(name: name)

// Switch to emulator
let auth = Auth.auth(app: app)
auth.useEmulator(withHost:"localhost", port:9099)
auth.settings?.isAppVerificationDisabledForTesting = true
self.auth = auth

let db = Firestore.firestore(app: app)
let settings = db.settings
settings.host = "localhost:8080"
settings.isPersistenceEnabled = false
settings.isSSLEnabled = false
db.settings = settings
self.db = db

let storage = Storage.storage(app: app)
storage.useEmulator(withHost:"localhost", port:9199)
self.storage = storage

Upload:

// Auth
// ...
let uid = auth.currentUser?.uid

// Upload file
storage.maxUploadRetryTime = 3
let storageRef = storage.reference()
let ref = storageRef.child("/users/\(uid)/xxx/yyy/image0.png")
let metadata = StorageMetadata()
metadata.contentType = "image/png"
ref.putData(imageData.pngData, metadata: metadata) { metadata, error in
     if let error = error {
          // ...
     } else {
          // ...
     }
}

[REQUIRED] Expected behavior

File is uploaded to Storage.

[REQUIRED] Actual behavior

Permissions error.

Error Domain=FIRStorageErrorDomain Code=-13021 "User does not have permission to access gs://aaa.appspot.com/users/Lv0O2wJBQhII3IzgApemOm5ahLUX/xxx/yyy/image0.png." UserInfo={object=users/Lv0O2wJBQhII3IzgApemOm5ahLUX/xxx/yyy/image0.png, ResponseBody={"error":{"code":403,"message":"Permission denied. No WRITE permission."}}, bucket=aaa.appspot.com, data={length = 74, bytes = 0x7b226572 ... 2e227d7d }, data_content_type=application/json; charset=utf-8, NSLocalizedDescription=User does not have permission to access gs://aaa.appspot.com/users/Lv0O2wJBQhII3IzgApemOm5ahLUX/xxx/yyy/image0.png., ResponseErrorDomain=com.google.HTTPStatus, ResponseErrorCode=403}

Additional info

Same rules are working good in real Storage. Also 'request.auth' is working well in Firestore emulator.

[abeisgoat]

This could be an issue with parsing the credentials from the iOS SDK. I'll look into it.

[Frank-D]

Hi,
I'm having the exact same issue, "request.auth" always null in storage.rules when running an iOS simulator app (in my case, using flutter..) against the local firebase emulators, even if my user is fully authenticated with firebase auth.

Actually, the exact same code is working perfectly fine uploading files to local firebase storage emulator, when running the same app on the Android Emulator (..using Pixel 3a API 30 - Android 11.0), as opposed to running the same code/app with the iOS Simulator, which is throwing that permission denied error --> request.auth is null.

Temporary workaround until this bug is fixed is to replace any if request.auth != null condition reference in storage.rules with if true.. :/

[ENVIRONMENT INFO]
flutter: 2.5.2
firebase_storage: ^10.0.5
firebase-tools: 9.18.0
emulator/simulator: ios simulator iphone 13
os: macOS Big Sur 11.4
code editor: vs code

I guess it could be caused by a few different things, but found a similar but different bug/resolution around fb 'firestore' rules, in case it could help resolution or current fb 'storage' rules bug..

---

@abeisgoat, I don't want to be a pain, but since it's been 3 months since your last msg on this one, any progress or ETA here?
(btw, possible dup: #3550, even though I find current to be more concise and going straight to the point, I would rather keep current opened if both are the same..)

Thanks!

[tohhsinpei]

I believe this issue is a duplicate of #3550, which should be fixed by #4210.