Lets say we have a telegram bot running on node.js using node library: node-telegram-bot-api
Do we need to worry about any security problems, like can someone hack my server and access the source code or data through the API connection?
Don't worry about it, every API connection is through HTTPS, which is regarded as safe.
Related
I know that we can use a Firebase backend function to send an HTTP request to Google Apps Script and receive it using "doGet()".
However, is it possible to call a Google Apps Script function from Firebase without sending an HTTP request (since it's part of the same Google account)?
My concern is with security, where one may be able to guess/sniff the right URL/parameters and then execute the Google Apps Script function (which makes a purchase). Alternatively, there may be a proper way to secure GAS web apps.
There are quite some details missing. But I think you're asking of a Google Cloud Functions/Cloud Functions for Firebase can call into an Apps Script web app or a Apps Script REST API. The answer is that they indeed can invoke those URLs (if they're publicly accessible and fall within your quota).
But that is no more security risk than that any browser can invoke these URLs. The security should not come from knowing or being able to call the URLs. If you want to secure an API, you should implement proper security on it. For more on see Authorization for Google Services in Apps SCript
For a little project I want to send push notifications directly from the app (without a backend).
As I read from the FCM documentation while this is technically possible with a simple HTTP POST request it's discouraged because in this way I have to hard-code the server key that will become easily retrievable with a little of reverse engineering.
So I though to add my server key in the Firebase remote configuration and use that.
What do you think? Are there some contraindications?
Thank you very much.
Storing the key in Firebase Remote Config doesn't make the approach secure. After all: the app still needs to be able to access the key and thus remote config.
Any solution that uses the server key in the client-side code is susceptible to abuse.
Is it recommended to manage users in the client side or in the server side?
I'm worried about the authentication that has to be done in the client side if I manage the users in the client side.
Yes, you should manage user data on the server. Firebase already provides facilities for this: https://firebase.google.com/docs/auth/users
I run at the same problem it seems that Java server side API in firebase-admin JAR lacks these methods.
Red line in documentation https://firebase.google.com/docs/auth/admin/manage-users confirms that :(
In an interesting blogpost about 'Firebase Authentication with the Firebase 3.0 SDK and Auth0 Integration', it is stated that:
You can even have Firebase communicate with Webtask!
Now I can imagine the (web)client triggering a Firebase operation and subsequently a Webtask, but not the other way around. Or am I missing something?
Firebase can run as a serverless app, but it can also run on the server. You can even have Firebase communicate with Webtask! (sic!)
I think that paragraph is misleadingly phrased, perhaps it was just added at the last minute to spark interest. You can have a webtask communicate with Firebase, not the other way around. You don't "run Firebase" on your server either.
TL;DR: A client application may call a webtask with an HTTP request, and that task can read/write the database, but not in any other order.
Here's a quick and dirty reality check as of Nov. 2016:
The Realtime Database by itself does not provide you with a way of executing code. This includes responding to database changes and user requests, handling fan-in and fan-out operations, etc. There is no support for webhooks either.
Which means you have to provide your own execution environment for such logic on a custom server, or you can try to cram as much as possible into the client code. This is a pretty exhaustive topic by itself.
Webtasks are short-lived functions that respond to HTTP requests. Their lifecycle always starts with a request, so they are not fit for continuously watching the database for changes. But they are perfectly valid for handling requests coming in from your client application.
As you can store "secrets" for the webtasks, you can authenticate the task on an admin access level. This gives you the possibility to verify client tokens – which should be sent along with the request –; perform complex authorization and validation, and perform RTDB write operations you wouldn't trust the clients with.
Or trigger external services securely. The possibilities are close to endless.
I have a meteor application (with meteor Accounts), and am building a mobile application. How do I authenticate users from the mobile app. I have a python webservice that can send data to mobile clients. But I have no clue how to authenticate from the external app.
I did look at DDP client, but there is no 'authenticate method'. Is there any way to do this with a pure python solution? I have access to the 'users' collection -> srp verifier and salt.
Note: Python srp didn't work. The salt and verifier generated by python srp are supposedly bytes. However I can't even decode them using bytes.decode(encoding)
It sounds like you want to use the out-of-box account management baked into Meteor, then surface a mechanism that your PHP code can call to show different information based on who is authenticated.
If that's correct, I think your best bet is:
Build a PHP DDP Client. Meteor isn't really built to expose webservices in a traditional sense, but rather surface what they call a DDP protocol for external sources to plug into the server-side publications. That said, I have not yet found a PHP DDP client, but here is one in node, and one in .NET. You'll want to build a PHP DDP client and then write a Meteor.method in the Meteor server code that you can remotely call from your DDP client to check for a user's authentication.
BUT, if all you're doing is surfacing marketing information in your PHP site, perhaps it makes more sense to either (1) keep the entire app in PHP and use a native PHP account management system, or (2) save yourself the trouble of the DDP overhead and write the exposed marketing page directly in the Meteor app? If you need to keep it from a different server, consider a simple iframe?
I just developed a DDP client for PHP, which might be what you need. Check it out here :
https://github.com/zyzo/meteor-ddp-php