Amazon Cognito Identity Pool ID is NOT REQUIRED for non federated auth

[spendres]

The online manual states under Manual Setup that:

REQUIRED - Amazon Cognito Identity Pool ID.

But this is only true for Federated auth.

see: https://aws.github.io/aws-amplify/media/authentication_guide#common-authentication-use-cases under section 'Manual Setup'

My pool uses AWS-auth (non-federated) and works fine without it.

[Jun711]

Hi @spendres

Could you share the lines that you have at Amplify.configure()? Is it like this?

Amplify.configure({
    Auth: {
        region: 'XX-XXXX-X',
        userPoolId: 'XX-XXXX-X_abcd1234',
    }
});

[spendres]

Hi Jun,

My config object looks like this:

Amplify.configure({ Auth: { region: 'us-east-2', userPoolId: 'us-east-2_XXXXXXXXX', userPoolWebClientId: 'XXXXXXXXXXXXXXXXXXXXXXXXXX' } });

Best, Steve

On Thu, Mar 29, 2018 at 1:58 PM, Jun Goh notifications@github.com wrote:

Hi @spendres https://github.com/spendres

Could you share the lines that you have at Amplify.configure()? Is it like this?

Amplify.configure({ Auth: { region: 'XX-XXXX-X', userPoolId: 'XX-XXXX-X_abcd1234', } });

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws/aws-amplify/issues/500#issuecomment-377320122, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlV4NvSDp3S8ipfGwKSFGMUyb9xqbwEks5tjSCogaJpZM4S3RxO .

[AbhideepChakravarty]

As per your example given at https://github.com/aws/aws-amplify/blob/master/docs/media/authentication_guide.md

// REQUIRED - Amazon Cognito Identity Pool ID identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab'

is not needed. We are so badly stuck at the logout process. The /logout URL is not killing the token. Token remains alive even after login. Hoping amplify would help but it mandates identityPoolId which is not needed in case of non federated user.

Please respond.

[spendres]

Are you calling Auth.signout() during the logout process? The token is a temporary credential, so I don't think the JWT would be destroyed until you call the global signout. That is, an Auth.signout() by Amplify from your federated app, wouldn't preclude the user from using other resources or other federated apps if they existed at the creation of the token.

On Mon, Apr 9, 2018 at 11:57 AM, AbhideepChakravarty < notifications@github.com> wrote:

As per your example given at https://github.com/aws/aws- amplify/blob/master/docs/media/authentication_guide.md

// REQUIRED - Amazon Cognito Identity Pool ID identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab'

is not needed. We are so badly stuck at the logout process. The /logout URL is not killing the token. Token remains alive even after login. Hoping amplify would help but it mandates identityPoolId which is not needed in case of non federated user.

Please respond.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws/aws-amplify/issues/500#issuecomment-379802366, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlV4FfL3LafMcFI-iZ8EErPUhChSsHsks5tm4T7gaJpZM4S3RxO .

[AbhideepChakravarty]

There are two concerns: 1- I am not able to create the Auth object as it is mandatorily asking for identityPoolId, which I dont have because I dont need. I am not able to proceed. Identity Pool Id must not be REQUIRED field because people can only use User Pool. Making IdentityPoolId mandatory forces the Amplify user to have Federated Identities. That might not be required in many cases like yours. 2- Calling globalSignout is wrong because the purpose is to signout the user from all the devices he is logged into the application.

Now if you are saying that you dont kill the token because it will make user exit from all other federated apps, then Cognito design of creating an token is not right. A token must be for a device and the app. So that when a user signs out his token gets invalidated for that app only.

Cognito have the concept of multiple apps in one user pool. Any app can connect to any number of IdPs. Hence the token should also be app scoped. Isnt it?

[reyhaan]

I am in the same boat, had a look at Amplify's source code, they have made it mandatory to have identity pool id, why? If it's something that I am missing here then I would love to know but I just dont understand why identity pool id is mandatory?

[reyhaan]

Although I did add identity pool for my user pool and my life is once again happy, but I would really love to remove this identity pool, which I cant right now

[marcolanaro]

On the same boat: it's possible to workaround setting up federation identity. Still, if you want to integrate with appSync through API using AMAZON_COGNITO_USER_POOLS, it will not work because of this https://github.com/aws/aws-amplify/blob/master/packages/aws-amplify/src/API/API.ts#L290 AUTH needs to allow user pool authentication without federation identity.

[sreyseng]

@spendres Completely removing identityPoolId property from Amplify.configure still causes Auth.signIn to hit the error condition for me (I get "signin failed" error message). Although I do see tokens being populated when calling Auth.currentSession().

[marcolanaro]

Something very related that could help troubleshooting.

Assume Identity Pool ID is set up and this is the configuration:

Amplify.configure({
  Auth: {
    identityPoolId: process.env.REACT_APP_IDENTITY_POOL_ID,
    region: process.env.REACT_APP_REGION,
    userPoolId: process.env.REACT_APP_USER_POOL_ID,
    userPoolWebClientId: process.env.REACT_APP_USER_POOL_WEBCLIENT_ID,
    mandatorySignIn: true,
    cookieStorage: {
        domain: process.env.REACT_APP_DOMAIN,
        path: '/',
        expires: 365,
        secure: true
    }
  },
  aws_appsync_graphqlEndpoint: process.env.REACT_APP_GRAPHQL_URL,
  aws_appsync_region: process.env.REACT_APP_REGION,
  aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
});

Test:

Auth.signIn(username, password)
  .then(user => {
    console.log('user',user);
    Auth.currentSession()
      .then(session => {
        console.log('session',session);
      })
      .catch(err => console.log('session err',err));
  })
  .catch(err => console.log('user err',err));

Output:

Current behaviour: Inability to retrieve the session. Error: No current user.

Expected behaviour: Session retrieved with idToken, refreshToken, accessToken.

[annjawn]

Why is identityPoolId mandatory? I don't get it. We don't need Federated identities in our app. This doesn't make any sense. Falling back to amazon-cognito-identity-js is the only option we are seeing as of right now.

[spendres]

The main reason for having an IdentityPool is to assign a specific role to the users of that pool — that is, the one contained in the jwtToken. I have one Cognito User Pool that does not have an identity Pool and one that does and both have the same auth process. One is used as a self-registered and self-administered pool for a public app and the one with an Identity Pool uses the role to verify access to resources, beyond just a valid session.

Regardless of the federated sign on, the identity pool granularity seems to be designed to help separate types of users across services rather than solely by application.

To understand where AWS is headed with amplify, you have to run the awsmobile-cli and add backend features to your app. Then you can see the autogenerated yml files that are used to provison S3 or DynamoDB or Lambda APIs.

On Sun, Apr 15, 2018 at 7:36 AM, Marco Lanaro notifications@github.com wrote:

Something very related that could help troubleshooting.

Assume Identity Pool ID is set up and this is the configuration: Amplify.configure({ Auth: { identityPoolId: process.env.REACT_APP_IDENTITY_POOL_ID, region: process.env.REACT_APP_REGION, userPoolId: process.env.REACT_APP_USER_POOL_ID, userPoolWebClientId: process.env.REACT_APP_USER_POOL_WEBCLIENT_ID, mandatorySignIn: true, cookieStorage: { domain: process.env.REACT_APP_DOMAIN, path: '/', expires: 365, secure: true } }, aws_appsync_graphqlEndpoint: process.env.REACT_APP_GRAPHQL_URL, aws_appsync_region: process.env.REACT_APP_REGION, aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS', });

Test: Auth.signIn(username, password) .then(user => { console.log('user',user); Auth.currentSession() .then(session => { console.log('session',session); }) .catch(err => console.log('session err',err)); }) .catch(err => console.log('user err',err));

Output: [image: screen shot 2018-04-15 at 12 30 06] https://user-images.githubusercontent.com/1427910/38777981-3fd7804e-40a9-11e8-8bde-8eaf33c4f7b6.png

Current behaviour: Inability to retrieve the session. Error: No current user.

Expected behaviour: Session retrieved with idToken, refreshToken, accessToken.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws/aws-amplify/issues/500#issuecomment-381399548, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlV4J4h0Yo8t-gsw8z9p-9CczP7C5iZks5tozC0gaJpZM4S3RxO .

[spendres]

Also, you will see that the .configure data is auto updated within the mobile hub environment. I was lost until I deployed an awsmobile hub react app, then it all made sense.

On Thu, Jun 7, 2018 at 9:22 PM Steven Endres spendres@gmail.com wrote:

The main reason for having an IdentityPool is to assign a specific role to the users of that pool — that is, the one contained in the jwtToken. I have one Cognito User Pool that does not have an identity Pool and one that does and both have the same auth process. One is used as a self-registered and self-administered pool for a public app and the one with an Identity Pool uses the role to verify access to resources, beyond just a valid session.

Regardless of the federated sign on, the identity pool granularity seems to be designed to help separate types of users across services rather than solely by application.

To understand where AWS is headed with amplify, you have to run the awsmobile-cli and add backend features to your app. Then you can see the autogenerated yml files that are used to provison S3 or DynamoDB or Lambda APIs.

On Sun, Apr 15, 2018 at 7:36 AM, Marco Lanaro notifications@github.com wrote:

Something very related that could help troubleshooting.

Assume Identity Pool ID is set up and this is the configuration: Amplify.configure({ Auth: { identityPoolId: process.env.REACT_APP_IDENTITY_POOL_ID, region: process.env.REACT_APP_REGION, userPoolId: process.env.REACT_APP_USER_POOL_ID, userPoolWebClientId: process.env.REACT_APP_USER_POOL_WEBCLIENT_ID, mandatorySignIn: true, cookieStorage: { domain: process.env.REACT_APP_DOMAIN, path: '/', expires: 365, secure: true } }, aws_appsync_graphqlEndpoint: process.env.REACT_APP_GRAPHQL_URL, aws_appsync_region: process.env.REACT_APP_REGION, aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS', });

Test: Auth.signIn(username, password) .then(user => { console.log('user',user); Auth.currentSession() .then(session => { console.log('session',session); }) .catch(err => console.log('session err',err)); }) .catch(err => console.log('user err',err));

Output: [image: screen shot 2018-04-15 at 12 30 06] https://user-images.githubusercontent.com/1427910/38777981-3fd7804e-40a9-11e8-8bde-8eaf33c4f7b6.png

Current behaviour: Inability to retrieve the session. Error: No current user.

Expected behaviour: Session retrieved with idToken, refreshToken, accessToken.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws/aws-amplify/issues/500#issuecomment-381399548, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlV4J4h0Yo8t-gsw8z9p-9CczP7C5iZks5tozC0gaJpZM4S3RxO .

[annjawn]

That sounds like a LOT of un-necessary work especially for an app that has no need of a Federated Identity pool. And this is in terms of a server less React app. The documentation is also kind of all over the place. Also, for a serverless app, a bundle containing all my AWS configurations doesn't sound like a good idea. The bundling process is going to expose a whole bunch of stuff that I potentially don't want to. This all makes sense for Mobile apps, but this use "AWSMobile" for a web app, especially for a serverless one doesn't sound quite right.

[spendres]

I need all the other backend services that mobile hub offers, but was architecting it all myself with instances and containers. So using identity pools simplifies my life. But you are still not required to use an identity pool if you only need a user pool.

If you are getting a “no user pool” error then you need to update your libraries.

Sent from my iPhone

On Jun 7, 2018, at 9:46 PM, Anjan B. notifications@github.com wrote:

That sounds like a LOT of un-necessary work especially for an app that has no need of a Federated Identity pool.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jordanranz]

Going to close this issue due to inactivity. Please reopen if you have any related questions or concerns.

[adambiggs]

@jordanranz please reopen this. It's still totally unresolved...

[powerful23]

@adambiggs in the latest version of amplify you can use the auth module without providing a Cognito Federated Identity pool id.

[AbhideepChakravarty]

Awesome!!!

On Tue, Aug 14, 2018 at 10:42 PM Zhuo wen notifications@github.com wrote:

@adambiggs https://github.com/adambiggs in the latest version of amplify you can use the auth module without providing a Cognito Federated Identity pool id.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500#issuecomment-412947030, or mute the thread https://github.com/notifications/unsubscribe-auth/AInRzqILED28OFsUiPN0708a0PW8pJxoks5uQwTygaJpZM4S3RxO .

[adambiggs]

@powerful23 nice!

[annjawn]

Yes but Storage still needs a federated identity pool it seems.

[bsberry]

@annjawn I'm seeing the same thing. Very inconvenient.

[annjawn]

@bsberry I looked into it a little further and it kind of makes sense for Storage to have federated identity coz the only way you could assign a Cognito user any kind of S3 permissions is by assigning appropriate policies to the identity pool.

[0x6C38]

@annjawn that's not accurate, users can transitively be assigned permissions through cognito user pools groups

[annjawn]

@0x6C38 can you point me to some documentation on how to do it? We would love to do it and it would actually solve a few sticking issues for us because we intend to use User Pool with User Pool SAML federation.

[0x6C38]

@annjawn sorry I meant to say user pool groups. As for how to do it, just assign permissions to the groups and then make sure users are part of the group you want. I think amplify added support for external providers through user pools a few days ago but I haven't checked it out yet. If its possible to assign users who have signed up with external providers to cognito groups then granular authorization should be trivial.

I also found out yesterday that cognito identity pools support conditional role selection so you can apply roles based on claims or you can have automatic role resolution based on the token which works perfectly with roles assigned through user pool groups.

[annjawn]

@0x6C38 I see, so you are talking about assigning IAM roles to User Groups in the User Pools. I guess that is one way to do it but I am curious if the ID Token returned by Cognito in this case will contain the appropriate information for the STS assume role functionality. I am going to have to take a look at User Groups and assigning IAM roles to the group without having Identity Pool however I am not sure if Amplify's "Storage" submodule (for S3) will work without an identity pool since Identity Pool seems to be mandatory for Storage according to documentation.

import Amplify from 'aws-amplify';

Amplify.configure({
    Auth: {
        identityPoolId: 'XX-XXXX-X:XXXXXXXX-XXXX-1234-abcd-1234567890ab', //REQUIRED - Amazon Cognito Identity Pool ID
        region: 'XX-XXXX-X', // REQUIRED - Amazon Cognito Region
        userPoolId: 'XX-XXXX-X_abcd1234', //OPTIONAL - Amazon Cognito User Pool ID
        userPoolWebClientId: 'XX-XXXX-X_abcd1234', //OPTIONAL - Amazon Cognito Web Client ID
    },
    Storage: {
        AWSS3: {
            bucket: '', //REQUIRED -  Amazon S3 bucket
            region: 'XX-XXXX-X', //OPTIONAL -  Amazon service region
        }
    }
});

[0x6C38]

@annjawn yep, you're gonna need an identity pool if you want to allow your users to write directly to S3, although you could allow indirect access through a lambda or something if you want to get rid of identity pools badly enough.

That being said identity pools can be used in combination with user pool groups if you configure role selection in identity pools properly. I've tested this with user pools as an authentication provider and it works. The easiest way to set it up is to "choose role from token" and let automatic role resolution do the work.

The only problem with this is that external authentication providers other than cognito obviously don't have token claims regarding groups on their tokens. If its possible to set up external providers through user pools and assign those users to groups as if they were regular cognito pool users then that should solve everything, but I haven't tested that yet.

[masbaehr]

I'm still wondering why Identity pool is required to do such a simple task:

Amplify.configure({
 Auth: {
  region: 'eu-central-1',
  userPoolId: 'eu-central-1_XXXXXXXXX',
  userPoolWebClientId: 'XXXXXXXXXXXXXXXXXXXXXXXXXX'
},
API: {
  graphql_endpoint: 'https://XXXXXXXXXX.execute-api.eu-central-1.amazonaws.com/XXXXX',
  graphql_endpoint_iam_region: 'eu-central-1'
}
});

Login works without any issues, but when i try to call the api i get the error:

API - ensure credentials error No Cognito Federated Identity pool provided

However it should technically still be possible to create a valid request by using the data which is available after having logged-in correctly via Auth.signIn. Basically the only thing to do would be to create the valid Header with AWS v4 Signature.

[spendres]

I believe that the issue is a little more complicated. The way aws-amplify and aws-mobile are architected, they assume that a user may store information in the cloud and as such need to have an IAM policy to separate users from each other. It's not enough that the user pool has a unique id for each user, it's that IAM must enforce the policy when a user tries to upload a photo to S3 as part of a mobile app. This is why aws-mobile creates the IAM policy associated with backend AWS services. Otherwise, the user would have the role/policy associated with the entire user pool which only lets them authenticate to a Cognito user pool... not a "federated identify pool" as required by other AWS services.

This is the best I've come up with having used aws-amplify but then moving to aws-mobile. Aws-mobile sets up the front-end and back-end and manages the role/policy for an Identity pool that can use that back-end service, be it lambda, or S3, or DynamoDb.

I recommend you use aws-mobile to create a simple app and see what it does, then the architecture will make more sense.

On Thu, Jun 27, 2019 at 9:53 AM masbaehr notifications@github.com wrote:

I'm still wondering why Identity pool is required to do such a simple task:

Amplify.configure({ Auth: { region: 'eu-central-1', userPoolId: 'eu-central-1_XXXXXXXXX', userPoolWebClientId: 'XXXXXXXXXXXXXXXXXXXXXXXXXX' },API: { graphql_endpoint: 'https://XXXXXXXXXX.execute-api.eu-central-1.amazonaws.com/XXXXX', graphql_endpoint_iam_region: 'eu-central-1' } });

Login works without any issues, but when i try to call the api i get the error:

API - ensure credentials error No Cognito Federated Identity pool provided

However it should technically still be possible to create a valid request by using the data which is available after having logged-in correctly via Auth.signIn. Basically the only thing to do would be to create the valid Header with AWS v4 Signature.

Or am i doing something wrong?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500?email_source=notifications&email_token=AAEVLYA7JJG2GTQWXU7WFVDP4TA5RA5CNFSM4EW5DRHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYXF77Q#issuecomment-506355710, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEVLYEIC5CWHM3BCR2EWULP4TA5RANCNFSM4EW5DRHA .

[cyrfer]

I believe this ticket should be re-opened.

I am successfully using the AmplifyJS client to use the Cognito Hosted UI as a passthrough to Okta Hosted UI for authenticating users with SAML 2. This uses only a User Pool with a Federated IdP. No identity pool is required.

However, I see an error in my browser's console, Uncaught (in promise) No Cognito Federated Identity pool provided

This line of code seems to be the culprit. https://github.com/aws-amplify/amplify-js/blob/8648b0c844cfa97f955f40f88ce6bceaf53b98a3/packages/core/src/Credentials.ts#L153

I want to avoid the uncaught promise.

@jordanranz

[bbbryan14]

I believe this ticket should be re-opened.

I am successfully using the AmplifyJS client to use the Cognito Hosted UI as a passthrough to Okta Hosted UI for authenticating users with SAML 2. This uses only a User Pool with a Federated IdP. No identity pool is required.

However, I see an error in my browser's console, Uncaught (in promise) No Cognito Federated Identity pool provided

This line of code seems to be the culprit. https://github.com/aws-amplify/amplify-js/blob/8648b0c844cfa97f955f40f88ce6bceaf53b98a3/packages/core/src/Credentials.ts#L153

I want to avoid the uncaught promise.

@jordanranz

I feel the pain, I use Sentry and I'd see tons of unhandled promise rejection.

[spendres]

This is a tough one since there has to be some boundary to the expected domain of the module. If you provide your own federated identify manager, then that should fall into the normal use pattern and should produce no unhandled promise rejections.

On Fri, Jan 31, 2020 at 3:48 PM bryan notifications@github.com wrote:

I believe this ticket should be re-opened.

I am successfully using the AmplifyJS client to use the Cognito Hosted UI as a passthrough to Okta Hosted UI for authenticating users with SAML 2. This uses only a User Pool with a Federated IdP. No identity pool is required.

However, I see an error in my browser's console, Uncaught (in promise) No Cognito Federated Identity pool provided

This line of code seems to be the culprit.

https://github.com/aws-amplify/amplify-js/blob/8648b0c844cfa97f955f40f88ce6bceaf53b98a3/packages/core/src/Credentials.ts#L153

I want to avoid the uncaught promise.

@jordanranz https://github.com/jordanranz

I feel the pain, I use Sentry and I'd see tons of unhandled promise rejection.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500?email_source=notifications&email_token=AAEVLYH3YDWCANRFWEM423LRASFDPA5CNFSM4EW5DRHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKP6USQ#issuecomment-580905546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVLYGQVJCWZYTOLXUSNLTRASFDPANCNFSM4EW5DRHA .

[jvsteiner]

Why would handling the rejection of a promise created inside this module not be within the expected domain of this module?

[spendres]

I agree. He who creates the promise should handle any rejection. In this case it looks like a timeout should trigger the rejection.

On Sun, Oct 18, 2020 at 12:37 PM Jamie Steiner notifications@github.com wrote:

Why would not handling the rejection of a promise created inside this module not be within the expected domain of this module?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500#issuecomment-711280898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVLYHEXJKCOYFTCBFMMW3SLMKVZANCNFSM4EW5DRHA .

[jvsteiner]

My frustration is that I am creating a vue app, using aws-amplify. I followed all the tutorials and sample code. When I refresh the screen, first time, the user is found, but the session is null. second refresh, everything is gone. I have everything enabled to recognize devices, store in local storage, etc. This is the fundamental basic thing that this library should be doing. It weighs over 70 kB (!!!) and yet it doesn't do the one single thing that it should do reliably. The aws github pages are littered with various threads on related topics - all closed, but with people still saying they have the same problem years later. With react, with plain cognito, doesn't matter. Sessions are not persisted, logins cannot be saved between visits. It is absolutely shameful that a 70kB library cannot manage to store a few bytes in storage reliably, and abstract this from the developer in a reliable way. No wonder Auth0 and okta are still in business at 10x the price - probably their products work!!

[spendres]

Realize that you have to have setup your cognito pool to allow unauthenticated users? The library works with JWT to support multiple applications that have policies declared in the token. So it doesn’t use typical http sessions. Because they police the APIs for denial of service attacks, it does take more work to set the policies and groups using the user pools and federated users/groups.

There is a cloud formation stack example that should help you. Let me track it down when I get back to my desk. It worked at least, which is better than spinning your wheels.

On Sun, Oct 18, 2020 at 3:48 PM Jamie Steiner notifications@github.com wrote:

My frustration is that I am creating a vue app, using aws-amplify. I followed all the tutorials and sample code. When I refresh the screen, first time, the user is found, but the session is null. second refresh, everything is gone. I have everything enabled to recognize devices, store in local storage, etc. This is the fundamental basic thing that this library should be doing. It weighs over 70 kB (!!!) and yet it doesn't do the one single thing that it should do reliably. The aws github pages are littered with various threads on related topics - all closed, but with people still saying they have the same problem years later. With react, with plain cognito, doesn't matter. Sessions are not persisted, logins cannot be saved between visits. It is absolutely shameful that a 70kB library cannot manage to store a few bytes in storage reliably, and abstract this from the developer in a reliable way. No wonder Auth0 and okta are still in business at 10x the price - probably their products work!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500#issuecomment-711412555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVLYD5S5QTNL5S3BU5QATSLNBCPANCNFSM4EW5DRHA .

[spendres]

In the meantime, you can visit www.airportslotauction.com and self register using your email to see a working process. It’s a mock site so there is no money required to just register to watch the http headers and JavaScript.

On Sun, Oct 18, 2020 at 3:48 PM Jamie Steiner notifications@github.com wrote:

My frustration is that I am creating a vue app, using aws-amplify. I followed all the tutorials and sample code. When I refresh the screen, first time, the user is found, but the session is null. second refresh, everything is gone. I have everything enabled to recognize devices, store in local storage, etc. This is the fundamental basic thing that this library should be doing. It weighs over 70 kB (!!!) and yet it doesn't do the one single thing that it should do reliably. The aws github pages are littered with various threads on related topics - all closed, but with people still saying they have the same problem years later. With react, with plain cognito, doesn't matter. Sessions are not persisted, logins cannot be saved between visits. It is absolutely shameful that a 70kB library cannot manage to store a few bytes in storage reliably, and abstract this from the developer in a reliable way. No wonder Auth0 and okta are still in business at 10x the price - probably their products work!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500#issuecomment-711412555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVLYD5S5QTNL5S3BU5QATSLNBCPANCNFSM4EW5DRHA .

[spendres]

this was the stack that helped me see a working configuration:

https://aws.amazon.com/blogs/mobile/appsync-realtime/

It's a react application and stack.

On Sun, Oct 18, 2020 at 4:18 PM Steven Endres spendres@gmail.com wrote:

In the meantime, you can visit www.airportslotauction.com and self register using your email to see a working process. It’s a mock site so there is no money required to just register to watch the http headers and JavaScript.

On Sun, Oct 18, 2020 at 3:48 PM Jamie Steiner notifications@github.com wrote:

My frustration is that I am creating a vue app, using aws-amplify. I followed all the tutorials and sample code. When I refresh the screen, first time, the user is found, but the session is null. second refresh, everything is gone. I have everything enabled to recognize devices, store in local storage, etc. This is the fundamental basic thing that this library should be doing. It weighs over 70 kB (!!!) and yet it doesn't do the one single thing that it should do reliably. The aws github pages are littered with various threads on related topics - all closed, but with people still saying they have the same problem years later. With react, with plain cognito, doesn't matter. Sessions are not persisted, logins cannot be saved between visits. It is absolutely shameful that a 70kB library cannot manage to store a few bytes in storage reliably, and abstract this from the developer in a reliable way. No wonder Auth0 and okta are still in business at 10x the price - probably their products work!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aws-amplify/amplify-js/issues/500#issuecomment-711412555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVLYD5S5QTNL5S3BU5QATSLNBCPANCNFSM4EW5DRHA .

[github-actions[bot]]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.