Cognito's sub field (user-persistent) should be used for Storage rather than the identityId field, which is session-persistent.

Describe the bug The Storage class generates a filename prefix based on the IdentityId of the Cognito User. The correct identifier is the “sub” field of the cognito user. The sub field is also used in the S3 policy template, which is further evidence that the identityId field is the incorrect choice.

The naming schema is a little confusing, but I believe that identityId is a session id. So if you log out and then back in, it should reproduce this issue. I believe that the sub field is short for subject, which indicates a longer-term identifier for an end user.

To Reproduce This bug can be seen clearly in the code in the _prefix method: https://github.com/aws-amplify/amplify-js/blob/master/packages/storage/src/Storage.ts

Isolating the session behavior is a little tricky, but I believe you can reproduce this bug by:

//Pseudocode -- I will put a complete demo together if people agree that this is unintended behavior.

Auth.signUp( userInfo );
Auth.signIn( userInfo );
console.log( Auth.currentUserInfo() ); // Take note of  CognitoUser.storage.cognitoIdentityId
Storage.put( 'file1.jpg', {level: 'private'});

Auth.signOut({global: 'true'});
Auth.signIn( userInfo );
console.log( Auth.currentUserInfo() ); // Take note of  CognitoUser.storage.cognitoIdentityId (it should be different than the previous value.
Storage.put( 'file2.jpg', {level: 'private'});
Storage.get('file1.jpg', {level: 'private'}); // 402 Error. Should not be able to access the file.

I would expect that the above procedure to place file1.jpg in the same folder as file2.jpg, but it places them in two separate folders because cognitoIdentityId changes when the user signs in -> signs out -> signs in.

Expected behavior The location of files uploaded with Storage by a single user should persist after an Auth.signIn(): Auth.signOut() cycle. The user should be able to access files that they uploaded before signing out and then back in.

Desktop (please complete the following information):

• OS: Mac OS
• Browser: Chrome

Additional context

If people agree that this is a bug, I’m happy to put more effort into a full demo and a PR. The distinction between cognitoIdentityId and sub is quite confusing. I also suspect that cognitoIdentityId === sub immediately after the user signs up, but that cognitoIdentityId changes after the user is issued new tokens by logging out and back in.

[babus]

@jordanranz It’s advised to use cognito:sub as the user identity in Amplify CLI projects. The question should have been put different. This should be using cognito:sub as the policies says so. Otherwise we will have User table with id field values with cognito:sub at backend and the storage bucket contain the user data under cognitoIdentityId which is very confusing and also make it tough to fetch other user data from the storage with ‘protected’ level.

[jordanranz]

Hey @ajhool, apologies for the late response.

When you use signIn with the same userInfo as highlighted in the pseudo code, the signed-in user credentials will contain the same cognitoIdentityId as before, so it is not session-persistent for authenticated users.

Storage.get('file1.jpg', {level: 'private'}); // 402 Error. Should not be able to access the file. mentioned in your pseudo code would not throw a 402 and show allow the user to access this file assuming you are signed in as the same user.