I am trying to add AWS Cognito to my iOS application using AWS Amplify. The docs suggest to use amplify add auth on the CLI, but this does not seem to work with an existing User Pool (i.e. you have to create a new one). Is it possible to integrate AWS Cognito into my iOS (Swift) project using an existing User Pool?
Amplify CLI doesn't support existing resources at the moment but you can manually edit your awsconfiguration.json to include the User Pool that is already present as outlined here.
Update: Since 2020 Amplify allows you to use existing User Pools (yeah!). Just run:
amplify import auth
Source: https://aws.amazon.com/de/about-aws/whats-new/2020/10/use-existing-cognito-user-pools-identity-pools-for-amplify-project/
Related
I'm creating flutter application with Firebase authentication. But I need to store some recording files (mp3) to cloud storage. I need to use aws s3 as a requirement. So I tried to integrate the that with flutter.
I have found official plugin called amplify_storage_s3 on pub.dev
But I had to read from documentation I need to amplify authentication to use that.
I don't want to use amplify auth because I'm already done it with firebase authentication.
So what I can do?
We have two projects -
Project 1 - Google App engine standard python 2.7.
Project 2 - Google Appp engine standard python 3.3
Project 1 application is secured using Firebase user authentication.
We have a need to access a particular function (URL) of Project 1 accessing from Project 2. The call from Project 2 will be done by the server (not user). We need this to be secure.
Can we enable just this function (URL) in Project 1 with IAP? And use the instructions here to authenticate?
It the above is not a solution, what are our options?
Yes, the link you provide exposes proper solutions. Although, I believe the best one is to use a Service Account for Project 2 that allows access to Project 1 resource (Use the proper Cloud Function role).
Include the Service Account credentials in Project 2 and use the proper library to call the service using the Service account credentials. Learn how to create a Service account credential here
We have an older application based on the AppEngine SDK (now deprecated) and the superseded Cloud Datastore.
In the process of migrating to Google Cloud SDK we also decided to move from JPA/Datanucleus to Objectify.
Given that the Cloud Datastore will be automatically upgraded to Cloud Firestore in Datastore mode sometime in the future, we decided to test our application as described at the bottom of this page:
https://cloud.google.com/datastore/docs/upgrade-to-firestore#testing_an_existing_application
1) Create a new project. In this project, create a Cloud Firestore in Datastore mode database.
2) Using the managed export service, export some of your application's data to Cloud Storage.
3) Using the managed import service, import your application's data to your new project.
4) Copy app logic you want to test to the new project or simulate app behaviour against the new project.
That's what we did and after some issues we could make a portion of our application run fine with the new datastore in a separate test project.
Now to the actual issue...
We wanted to test if the updated application could also run with the superseded Cloud Datastore, so we won't have to worry when the automatic upgrade occurs (as our app will be already ready).
So we deployed it as a new version of the existing AppEngine project (v2-dot-.....): unfortunately running the new version throws a permission error as soon as the app tries to read the datastore:
com.google.cloud.datastore.DatastoreException: Missing or insufficient permissions
So the questions are:
- could this be related to the Cloud Datastore not being upgraded to Cloud Firestore in Datastore mode for our project yet?
- is there anything we can do (add specific permissions maybe) to make it work anyway?
Our concern is that we need to have the new version of the app deployed before July 2020 (that's when the older AppEngine SDK will stop working), and we are worried that the automatic upgrade of the datastore will occur later.
Thank you for your help.
Turned out our project doesn't have the PROJECT_ID#appspot.gserviceaccount.com member in IAM.
It has a pletora of other members (for example: PROJECT_NUMBER-compute#developer.gserviceaccount.com, PROJECT_NUMBER#cloudservices.gserviceaccount.com, service-PROJECT_NUMBER#compute-system.iam.gserviceaccount.com, etc) which I guess are legacy members used in previous versions of Google App Engine.
Adding PROJECT_ID#appspot.gserviceaccount.com with the role Editor fixed the issue: now the new version can be deployed to the old projects and it works fine even if the datastore has not yet been converted to Cloud Firestore in Datastore Mode.
I just ran into this issue and spent way too much time troubleshooting it. Nine times out of ten if you're running into this issue it's because the default App Engine service account doesn't have permission to edit Cloud Datastore. The default App Engine service account is used by default if you're doing a simple gcloud app deploy and nothing else fancy. I solved the problem by giving the default App Engine service account the roles/datastore.owner role with the following:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:PROJECT_ID#appspot.gserviceaccount.com" \
--role="roles/datastore.owner"
Although awsmobile-cli has a feature for enabling and configuring an AppSync backend like:
awsmobile appsync enable
awsmobile appsync configure
It is prone to end up with a total irrelevant configuration: It creates DynamoDB tables in us-west-2 (Oregon), even if my project is located at eu-central-1 (Frankfurt). And it does so through its default "events" graphql schema. And after all, it does not appear on the MobileHub project console as a backend feature.
Now, the thing I want to do is adding an AppSync backend to AWS MobileHub project via the console. And then I can pull the changes from the cli once I am done i.e. modified the my graphql schema, attached the resolvers and engaged the datasources.
Is it possible as of now?
Unfortunately right now this is not possible via the Mobile Hub console. It is in the CLI roadmap to support importing existing AppSync resources.
As it is not possible to on Mobile Hub right now you could try to use serverless framework together with serverless-appsync-plugin. It allows you to write your infrastructure as code and to deploy it to AWS via CLI.
While Mobile Hub is kinda limiting, you can actually design more complex backend for your app with serverless tool. You can even set up lambda data sources for appsync. Here you can find some examples for different graphql API setups: https://github.com/serverless/serverless-graphql
If you have more or less complex schema it is a right solution to deploy it from CLI as AppSync console starts to lag with big schemas
I have a Webapp hosted on Google compute engine. I am trying to list it on Microsoft AppSource. One of the mandatory conditions for listing is enabling Azure Active Directory federated Single Sign-on (AAD federated SSO) for the app.
Google Cloud platform supports SAML 2.0-based SSO. Hence technically this should be possible. Has anybody tried it and any has experiences to share. Thanks in advance.
In order for an application to integrate with Azure Active Directory - it is not required that you have an Azure Subscription, or even Azure Active Directory (specially if your application is a multi-tenant application) - you can host your application anywhere.
For AppSource, as long as your app integrates with Azure Active Directory, then you are able to list your app on AppSource - which means that the application does not need to be hosted in Azure. AppSource also requires Open Id Connect - SAML would not qualify. For more details please see this article.
To make it easier to test the Azure AD integration in your application, you can create/ use a test tenant with a Microsoft personal account (MSA), as well as use this MSA account to register your application for OAUTH2 flow.
You probably don't want to use GCP's SSO. This is really designed to allow your developers to use your organization's auth system while working on GCP. This is different than allowing your users to use their organization's AD while working within your web app.
Instead, I suggest you look to see if anyone has built AD or SAML integration for the framework your webapp is built with, or look to implementing it yourself. This allows the SSO auth to be used for the app itself, instead of in accessing GCP APIs.