We Keep Coding

Use Firebase and API keys to authenticate paid Shopify website themes

I'm trying to use Firebase as an authorization method for a paid Shopify website theme. The idea is the store owner purchases and downloads the theme files, and after purchasing also creates a firebase account with an email and password. Then an API key for the theme will be emailed to them. Once they have the API key they will input their account email and API key into the settings within the theme files. To authenticate the user the theme files will have some javascript that checks if the username and password inputted correspond to a existing user in the firebase database. If the email and API key inputted does not match to any user in the database then the user will be redirected to an error message HTML file, or get an error message popup that they cannot close saying to input the correct key.
Another possibility is to use the firebase firestore unique user ID instead of generating user API keys. Maybe this way there would be no need for using the firestore database.
Either way, this logic seems ok if it was a single user. But since it is a website theme file it is possible that every users website will get thousands of customer visits per day. Thus every customer that visits the clients site will trigger an authentication check with firebase with the clients email and API. So every user account on Firebase could potentially have thousands or maybe even hundred of thousands of logins and database queries everyday (depending on how popular their website is). So this is the part Im worried about.
Anyone have similar experience using Firebase for website theme authentication? Perhaps I am going about it all wrong here. Or maybe Firebase is just the wrong tool for this job.
Appreciate any input!

Stripe: Setting up a card for future payments that is 3d secure authenticated

I've implemented the steps described in this Stripe tutorial on how to save card information to be used later on (future payments):
https://stripe.com/docs/payments/save-during-payment
This is now implemented and works fine.
I'm doing a 0.5$ charge on the card to trigger the 3d secure authentication process. How it works is that it first checks what is the PaymentIntent status, and if its "action_required" then it redirects to this HTML where I've implemented in JS the following:
function _3dsec(stripe_publishable_key, pi_secret) {
document.addEventListener("DOMContentLoaded", function(event) {
var stripe = Stripe(stripe_publishable_key);
stripe.confirmCardPayment(pi_secret).then(function(result) {
if (result.error) {
$("#3ds_result").text("Error!");
$("#3ds_result").addClass("text-danger");
} else {
$("#3ds_result").text("Card succesfully validated");
$("#3ds_result").addClass("text-success");
}
})
})
}
And this also works well, it does the 3D secure authentication if the card requires it. I've been testing only with Stripe cards. and then the idea is that i refund the 0.5$ as it was just used to authenticate the card.
However, in my product the charges are done afterwards. There is only a signup page with the user and payment information and then charges occur as the user is using my product. This works well for cards that dont need the 3D secure authentication, but for the cards that require the authentication I'm not able to create charges later on, and get the "3D secure authentication required" status on the PaymentIntent. And the customer is not able to authenticate it as they are not in the website during that time ("off session").
Is this 3d secure behavior only on the Stripe test cards, or how can I implement future card payments on a card that requires the 3d authentication?

Whether a transaction requires 3D Secure or not is a decision that's entirely up to the cardholder's bank. When 3D Secure is required due to regulations (e.g., SCA), Stripe will apply for exemptions whenever possible to limit the likelihood of transactions requiring authentication, but it isn't guaranteed. So, yes, when you go to production it is possible (but unlikely) that your customers will require 3D Secure on each transaction.
for the cards that require the authentication I'm not able to create
charges later on, and get the "3D secure authentication required"
status on the PaymentIntent. And the customer is not able to
authenticate it as they are not in the website during that time ("off
session").
In cases when you make payments off-session, you should set the off_session property to true when creating the payment intent:
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-off_session
Doing so tells Stripe to apply for off-session payments exemptions when you're live in production. You can test how these types of payments would behave by using the first regulatory test card in this table:
https://stripe.com/docs/testing#regulatory-cards
In most cases the exemptions should be sufficient and the payment shouldn't require authentication, but there is still a chance that the cardholder's bank will request 3D Secure for the transaction. For those cases, you will need to write logic on your end to notify your customer of the failed transaction and to bring them back on-session to process the payment.

Firebase Auth signIn distinction

On my website, I have two portals for login. Portal A is login for learners. Portal B is login for teachers.
Both learners' and teachers' accounts are located in the same Firebase project, in another words, both types of accounts are located in the same authentication space. Both portals use the same simple login code:
firebase.auth().signInWithEmailAndPassword(user_email, user_password).catch(function(error) {})
Currently, the learners can login at both portals, and same for the teachers. What I am trying to do is to prevent the teachers to login at the learners' portal and vice versa. I am not sure how to implement this. I have made a setCustomUserClaim to give an identity to the two types of accounts on the authentication token. But I can only grab the auth token once the user is logged in, not before I think. Also, I have a Firestore collection that stores all the info of the users including their identity. But each user's document is named with their corresponding UID. The latter can be grabbed once they login in as well. Any idea on how to implement this?

Firebase Authentication has no built-in way to distinguish between these two types of users. It simply authenticates the credentials that a user enters, and ensure that they're correct. If certain users can only access a certain application or certain data, this is information that will have to come from you.
The above is important to realize, so I'll repeat it: Firebase Authentication allows all users to authenticate as long as they provide the right credentials. It has no way to block access to authentication based on application-specific information, such as your user-type. This type of authorization logic is part of your application, both in code and (if you use a Firebase Database) of your server-side security rules.
A common way to implement your scenario is to add the information about the types of users to a database (such as Firebase's Realtime Database, or Cloud Firestore). In this data you could for example store the email addresses of all teachers.
Now with this information, your code can then determine whether the person who signed in to the site is a teacher or not. If they're a teacher signing in to the student web site, you can redirect them, and vice versa.

what if database goes to error when payment happened on front-side

I am making PayPal payment via redirection to PayPal. This means that payment will take place in the user's browser and get me the details of the payment on the front-side. After the payment happened, I need to store details so for later use, I will know that the user has paid already. As soon as the payment happens on the front-end, I make an API call to my server to store the details of the payment.
Question: What if payment takes place on the front-side and when making an api call to my server after that, it goes to error. I'm left with the scenario that the user hasn't paid for the product, even though he did. What can I do in this situation?

Implement IPN (Instant Payment Notification).
From the documentation:
PDT has a major weakness: it sends order confirmations once and only once. As a result, when PDT sends a confirmation, your site must be running; otherwise, it will never receive the message.
With IPN, in contrast, delivery of order confirmations is virtually
guaranteed since IPN resends a confirmation until your site
acknowledges receipt. For this reason, PayPal recommends that you
implement IPN rather than PDT.
[...]
Note: If your site must be notified of payments immediately, you can implement both IPN and PDT. However, if you do, your site will
receive two order confirmations for each sale. As a result, you must
be careful to take action (say, ship a product) on just one copy of a
given confirmation message.
Instead of IPN, you can also implement Web Hooks which are basically a reworked variant of IPN that uses more modern technologies and a more streamlined interface. See also When to use IPN and when WebHooks in PayPal as a notification mechanism?

facebook API login and data management

I was looking at the facebook tutorial here
I am having some generic questions about integration and data management of user profiles (slightly confused).
So let's forget the facebook API for a minute, upon normal sign up I use a database that I capture the user details like desired user name , password and email ,dob .
If I use the facebook api shall I write tjose details anyway on my db and create a random username / password for the user and associate it with the facebook name (create a new field) or it's best not to write any information on my db at all? And then they can just use fb every time that they need to login .
I guess fb login takes away the username and password completely and still provides me with some information e.g email , date of birth etc....

Basically you will need some way to differentiate between Facebook users and users that have logged in manually. They will pretty much share the same fields (you can even request the users DOB from Facebook).
In both scenarios, you'll want to have a record in your DB for the user. With regard to a unique identifier, you could easily use the user's Facebook ID. After the user has logged in, you should not differentiate between login methods.