I faced with such error
Request must contain either a valid (registered) AWS access key ID or X.509 certificate.
While trying to register an user via Cognito in DynamoDB Local. An user registers ok when I disconnect from DynamoDB and I can create an record in db programmatically.
The error comes from the DynamoDB. Please have a look:
http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html
Related
We are migrating users to the Firebase and for specific app reasons I need to create a verify token on the backend side.
So the schema is next -
I receive the user email and password from the user. Passing it to
the backend.
Backend generates a verify token, retrieves all the
info from Firebase, and informs the user.
I'm looking for some way to do it with firebase SDK, but I don't see any option.
I want to use Firebase Auth for my user login/registration process. Everything else should be handled by my own backend (spring boot app + postgres db).
Now I'm asking myself how I can synchronize a new created user to my user table in postgres. I thought about the following:
REST call through client - Everytime I get a success event from the firebase sdk I call an additional request to my backend which sends uid, username etc.
Problem: What if my backend call fails but the register process was successful ? That would lead to an inconsistent state since (at least thats what I understanded) I can't easily rollback. That would lead to situations where a user can login into my app without my backend knowing the user. This would crash/ invalidate all my following queries (e.g. search after user xyz would lead to no result even though he/she exists)
Check the existence of the user in the postgres database
Here I would query the uid from the database (which I got from the jwt) and create a new user if it doesn't exists in every incoming request.
Problem: The user query is a unnessecary overhead for every incoming request.
Trigger with cloud functions - When I understood it right firebase auth is firing events when a new user is created in cloud functions. This could be used to make the external api call.
Problem: I dont know what happens when my external rest call fails at this point. Can I rollback the registration ? Will I be ever catch this event again ? I also proably would have an eventual consistency situation, since I dont know when the cloud function triggers. Furthermore I would prefer not to include cloud functions to my stack
Is there any way how I could do this in a transactional manner ? Did anyone else tried is using sth simular ?
Thanks for every help!
The easiest way is actually to not synchronize auth data, but instead decode and verify the ID token of the user in your backend code.
This operation is (by design) stateless, although Firebase's own backend services often implement a cache of recently decoded tokens to speed up future calls with the same ID token.
Apparently, I finally came up with a different solution:
Register user per Firebase SDK (e.g. with email + pw method)
Make a post-call to my own registration api including the resulting uid from the previous step and some metadata
API creates a new user including a column with the UID + Fetches the firebase token of the user and adds an internal claim that references to the internal Postgres UUID via Admin SDK.
Frontend gets the created user and hard refreshes (very important, since the previously fetched token won't contain the newly added claim !) the firebase token and verifies that it contains the token. If it does -> everything is cool, if not some oopsie happened :) That will require a request retry.
Later when you start your app you can just check if the passed token contains the custom claim, if not open the sign up/sign in page.
Every endpoint except the one for registration should check if the claim is set. If not just forbid the request.
How to set custom claims:
https://firebase.google.com/docs/auth/admin/custom-claims#set_and_validate_custom_user_claims_via_the_admin_sdk
You can use the Firebase Admin SDK to create the user account from your back-end instead of from the client.
So first you create the user in your database, then grab the ID and use it to create a user with the same ID in Firebase.
If all goes well, send a confirmation to the client and sign it in using the same credentials they entered.
Why not creating an endpoint in your backend service and call this endpoint when a client side authentication succeeds?
This method should do 2 things:
decode token to get access to Firebase user object (Firebase Admin)
Compare Firebase user with your internal user table. if it doesn't exist you can create it using firebase user object, otherwise do nothing.
This solution allows you to do other nice things as well (Syncing user info between Firebase and your internal db, providing a way to let a frontend know if this user is new or not, ...) at a relative small cost (1 get call per sign in)
I am trying to figure out how OAuth2.0 (or something else entirely) can be used to handle a situation where a user who is calling a backend api, can only retrieve data relevant to that user.
For example:
Lets say I have a bank application, and the customer account information is located at "bank.com/account/{customerId}". How do I restrict access to this, so that other customers cannot see each-others bank account information? As anyone with an access token could get anyone's account info and Roles can't solve this.
I have come up with a potential solution to this problem using Firebase JWTs which is to access the header of the incoming request and compare the User ID in the body of the token to that of the data being accessed.
My gut tells me I am missing the bigger picture, as this problem must be a common phenomena, and I could not find the answer elsewhere.
My Environment is a Spring Boot backend utilizing the Oauth2.0 resource server pointing to the firebase project. Backend is connected to a Postgres database. Frontend is an Angular Application.
To ensure users can access only their own resources, you must write it in your Spring Boot application. OAuth2 only provides you an access token which you can use to find out who is calling you and what scopes he has granted.
But the security logic is up to you to implement. If you have a userId in URLs, you should check that it matches the userId from access token. If user data is stored in a database, you will probably need to add conditions to your SQL queries such as WHERE user_id = :userId.
You can also use scopes from an access token to grant only partial access to user's resources. It's useful if another application can access user's resources on his behalf. Such as reading person's name and email when logging in somewhere using Google/Facebook/Github.
I am attempting to set up the MTurkR R Package for the first time which requires Access Keys, both "Access Key Id" and "Secret Access Key" from AWS see: http://polmeth.wustl.edu/methodologist/tpm_v20_n2.pdf
However Amazon recently "removed the ability to retrieve existing secret access keys for your AWS (root) account." see here
I tried creating an IAM User and using their Access Key within the credentials() command, but get the following error:
Error (AWS.MechanicalTurk.UnacceptableIdentity):
AWS Identity and Access Management (IAM) user accounts cannot be used for Amazon
Mechanical Turk.
Is there any way around this issue? Do I have to wait for a package update?
I have a form where the user will enter the AWS Account Name, AWS Access Key, and AWS Secret Key and click submit to add the information to a table in a database. How would I validate the keys prior to them being added to the database?
The only reliable way to confirm not only the format, but also the validity of the keys, is to perform an operation using them.
Do something simple with the EC2 API that requires all three factors prior to storing them in the DB.
On a side note, please be sure you properly secure this database. If it is compromised, so will be as many AWS accounts as you store the credentials to.