Amplify-js: 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 [e-mail] 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 <
[email protected]> 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 [e-mail]
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 [e-mail] 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 [e-mail]
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. [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail]
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 [e-mail]
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 [e-mail]
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 [e-mail] 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 [e-mail]
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
.