Use secure rules for Firebase Storage Integration tests #5643
Conversation
schmidt-sebastian
force-pushed
the
mrschmidt/storagetests
branch
from
1bf2c81 to
c3a1e88
Compare
| @@ -136,37 +151,8 @@ - (void)testUnauthenticatedGetMetadata { | |||
| [self waitForExpectations]; | |||
| } | |||
|
|
|||
| - (void)testUnauthenticatedUpdateMetadata { | |||
There was a problem hiding this comment.
There is already an update metadata test.
| @@ -205,27 +191,8 @@ - (void)testDeleteWithNilCompletion { | |||
| [self waitForExpectations]; | |||
| } | |||
|
|
|||
| - (void)testUnauthenticatedSimplePutData { | |||
There was a problem hiding this comment.
This test also exists twice.
paulb777
force-pushed
the
mrschmidt/storagetests
branch
from
3ebb919 to
c773b50
Compare
| var storage: Storage! | ||
| static var once = false | ||
|
|
||
| override class func setUp() { | ||
| FirebaseApp.configure() | ||
| app = FirebaseApp.app() | ||
| auth = Auth.auth(app:app) | ||
| auth.signIn(withEmail: "[email protected]", password: "testing") { result, error in |
There was a problem hiding this comment.
Do we need to block on this?
| @@ -705,6 +716,16 @@ class StorageIntegration: XCTestCase { | |||
| waitForExpectations() | |||
| } | |||
|
|
|||
| private func signInAndWait() { | |||
| let expectation = self.expectation(description: #function) | |||
There was a problem hiding this comment.
I wonder if self can be omitted here?
There was a problem hiding this comment.
nope. Variable used within its own initial value
| * | ||
| * You can define these access rights in the Firebase Console of your project. | ||
| */ | ||
|
|
||
| NSString *const kTestUser = @"[email protected]"; | ||
| NSString *const kTestPassword = @"testing"; |
There was a problem hiding this comment.
BTW are public credentials an issue from b/155892305 perspective? We can move credentials to secrets (e.g. like Auth do).
There was a problem hiding this comment.
We are planning to do so as well.
|
Some of the Storage Swift Integration tests are now failing since they test with unauthenticated access. What should we do about the unauthenticated tests? |
|
@ncooke3 Yep - Working on it now trying to figure out why the tests are still failing on CI, even though they succeed locally. Any ideas or suggestions appreciated. |
|
@paulb777 Hmm does it have anything to do with the fact that the rules have changed for the storage container on the firebase console? When I run them locally, any current tests that does any writing fails because it is unauthenticated and the rules on the console have since changed to only allow writes if authenticated. Maybe this is what is making the CI fail? |
|
@ncooke3 Yes - the rules have changed, but the tests should now be signing in to authenticate |
paulb777
force-pushed
the
mrschmidt/storagetests
branch
from
72fc6c3 to
d026ea1
Compare
This changes the Storage Integration Test to use Firebase Auth with Email/Password sign in. I also removed some duplicate tests.
Addresses internal b/155892305
#no-changelog