I have a big problem.
My database and authentication runs over Firebase.
I want to update a user to premium by calling this:
function getPremium() {
firebase.database().ref('premium').child(user.uid).set({
premium: true,
})
Everything works great, user updated to premium.
Now a guy comes around who knows a little bit of javascript and Firebase
so he simply opened the dev tools and run this code:
firebase.database().ref('premium').set({
iRuinedYourSite: true,
})
What can I do about it?
Is it so unsecure or what am I doing wrong to prevent something like this?
If your client-side code can upgrade the user, then the user can upgrade themselves, full stop. There is nothing your code can do on the client that a sufficiently-motivated end user can't do from the client.
You need to have a server involved, gate-keeping the interaction.
You could use Firebase's NodeJS Admin SDK to run a simple NodeJS Server that handles all of the premium requests. The NodeJS Admin SDK overrides Firebase Security Rules so you don't need to worry about that. Here's a link: https://firebase.google.com/docs/admin/setup
Edit: You could also use Firebase Functions which is basically a NodeJS Server that uses a special package to interact with the database. Here a link: https://firebase.google.com/docs/functions/
Hope this helps!
For anyone who wants to accept PayPal payments with Firebase,
Connect your Firebase project with Zapier, then connect Zapier with your Paypal account and let Zapier handle everything. It will cost you 25$ / Month but will bring in the security you need.
Related
I'm working on a school project using vanilla HTML, CSS, and JS. When compete, we're expected to have the repo working via GitHub Pages. It's above and beyond the scope of the assignment, but I wanted to connect to a Firebase Firestore database.
The question is, how do I hide the API key/information, using only vanilla HTML, CSS, and JS (no frameworks), and have a working GitHub Pages demo for the instructor to mark?
I've looked at a number of websites and YouTube videos, but every tutorial I've come across is either using a framework or some stack of packages that would go against the 'rules' of the assignment. I can use a .env file, but to my understanding, because the repo is public the key would be public.
Any advice would be greatly appreciated.
The answer is .env files (sort of).
If you're building a frontend project and you're connecting the front end directly to your database, your credentials will be visible.
The correct way to handle keys is to put them in your backend API. Of course, when I asked this question, I wasn't "there yet".
Your backend API can have a public endpoint that listens to incoming requests. You don't need to include your database credentials in the request coming from your frontend app. It hits your backend api at its public endoint where your backend code then handles the incoming request. On your backend you have the connection to your database with the necessary credentials. This is how you are supposed to build it.
For beginners, you might want to try Google Firebase. With Firebase you can create Firebase Functions. With these, you can create a simplified API endpoint to target with your front-end requests. It triggers the Firebase Function to run, and inside this function, you can store your private keys/credentials. Because your Firebase Functions run on your own secure backend, the client never sees the keys.
If you're learning or familiar with Vue3, here's a good article to check out: https://www.bezkoder.com/vue-3-firebase/#more-9260
I am trying to integrate docusign with a React Native app I am building. My desired workflow is to have the user launch a remote signing envelope based on a template.
From the Node JS examples, eg009 seems to be the end result I am after. However, I am wanting to complete this with Axios/Fetch and Javascript.
My intended flow is to have the user enter in their name and email, and their spouses name and email. From there they press a submit button which sends the API call, and that is the extent of what the app does.
I am wanting the API call to then start the template flow, sending a document to sign via email to both that were entered into the app. I want the users to authorize themselves from the email, not the app. After both parties have signed, I want it sent to a third static email.
I do not want the users to have to authorize inside the app or be redirected anywhere. It seems a JWT would be best.
Does this seem possible? How would you suggest going about this?
I appreciate the help!
Looks like the JWT grant flow is the right fit for you here. Please see this article for more details: https://developers.docusign.com/platform/auth
There's no good solution for running DocuSign API calls from client as a result of CORS limitations.
Larry has some blog posts on this topic - https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-2
You could use something like AWS lambda which is not a server per-se, but gives you server capabilities without the hassle of a server.
Check also the latest blog by Larry on this topic which superficially covers using React for single-page apps.
I have built a webbshop in Vue js and everything is done but the payment method is missing. Do i need to have express to take charges to stripe? I do not have a server like express now. And if i need express to take charges from paypal sdk or stripe sdk how can i host it later so its not running on my localhost? Its running on localhost port 3000 so how can i make it work on a ftp later?
Anyone that can help me?
I have tried to implement stripe or paypal for a week know but it seems impossible.
PayPal Checkout will get that done for you: https://developer.paypal.com/docs/checkout/#
That doc guides you on setting this up directly in your JS app, or you can also use a server back-end with PHP or something else if you prefer.
This will give you PayPal, PayPal Credit, Venmo, and direct credit cards all in a single checkout integration.
I created a chatbot to work with my fanpage on Facebook. This was done with a node.js base. When I do a 'firebase init', I get a /public folder and lots of other stuff. I do 'firebase deploy', but my bot is never called. Is there a way for work this out?
I have this as a reference:
Hosting nodeJS app with firebase
Still I got some faith this is a different case. Thanks in advance!
Well, I believe I got the answer now. Firebase only supports hosting for frontend stuff. For a chatbot I'd use something like NodeJS, PHP or other backend tecnologies. Thus, Heroku is a good call.
You should be able to Cloud Functions for Firebase to write a chat bot - I believe you might need to use a paid plan because the free tier does not allow Functions to make outbound calls.
I found a gist that appears to be an actual Facebook chat bot using functions:
https://gist.github.com/mikkipastel/37fa011e3aea7ebb9941fb3dab6f1186
When I use Facebook's JS SDK to authenticate my app (using FB.init method) all I need is my App ID. It does not require my app secret and/or app key.
However when I used PHP SDK, it required my app secret (atleast the example I used to learn used the app ID and app secret both).
Is it secure and recommended to use the JS SDK for authentication ? How really does the authentication flow happen with the JS SDK ?
Thanks,
Vineet
I'm looking into how secure the authentication is also - I think things have changed since you asked this q, so perhaps this information was not correct when you asked.
The new version of the JS SDK uses OAuth 2.0. This is well documented - check out the OAuth 2.0 site for details.
Regarding the issue of whether the SDK needs the app secret - I'm having a little bit of confusion relating to this. On the app server side, the libraries indicate that the JS SDK signs the cookies using the app secret (see the function get_user_from_cookie in the facebook-python sdk) - however, it's completely unclear to me how the JS SDK can know the app secret. I'm guessing that it can obtain it dynamically from FB when it talks to FB directly in the authentication process, but I'm not sure.
(Edit: I think that the JS SDK gets the cookie signed with the app secret directly from FB - the JS SDK never knows the app secret).
Not fully answering your q, but perhaps shedding a little more light on how this works.
Another issue to be wary of is not to use the FB user object you get from the client for anything on the server side. This is because it would be really easy for someone make a script which instead of calling fb.api '/me' would send a "fake" JSON user object with another users ID to your app. If you're doing any kind of server side processing of the user then you really need to do some kind of server side authentication as well I think.
It's NOT safe, this is why you have the "Verify Fields" and "Not Verifying the Signature" paragraphs in the Advanced Registration document:
When you request facebook data, we
verify the form fields before
packaging them up in the
signed_request. This lets you assume
that all the data is genuine and saves
you from having to verify things. The
one problem that could arise, is a
smart attacker could change the form
fields and submit them to you, thereby
giving you unverified data.
Read that document for more information, I've also wrote a tutorial (an introduction about the plugin) and showed how to handle the fields attribute coming from client-side.