I am implementing an app that only contains webhooks and doesn't mention authentication in the API documentation. Is it possible to have just an instant trigger and a webhook without a connection?
A connection's main purpose is to store the credentials (sensitive data) in one place, so if the API provides no endpoints for webhook registration or it does, but they don't require authentication, then you can just assign the webhook to the Instant Trigger and leave the webhook's connection empty.
Related
So i'm making an app using React JS, Cordova, node backend and a mongo database. I want to integrate firebase cloud messaging (FCM) into my platform. I'm quite new to firebase, and developing in general, and i'm not quite sure where to initialise firebase. I currently have it integrated into the front-end and it's requesting permission to receive notifications, generating tokens, and receiving messages from the firebase console. However i'm not entirely sure where to go from here. Do I add it to my backend as-well?
If you can receive messages in your client app, your front-end work is done for the moment.
But to send messages programmatically, you will need to write back-end code indeed. That's because sending messages through FCM requires that you specify the FCM server key to the API, and as its name implies that key should only be used in a trusted environment, such as your development machine, a server you control, or Cloud Functions.
For more on this, have a look at:
The architectural overview of FCM
The documentation on your server and FCM
My answer to How to send one to one message using Firebase Messaging
You have to get the FCM token from the frontend (or, client app).
After getting the token, just send it to your backend server using a POST method.
Then, store the token in whatever database you're using in your backend. It can be MongoDB, PostgreSQL, etc.
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
I've been following a tutorial to build a full stack website using firebase, react and redux. Log in sends a call to a back end function which uses
firebase.auth().signInWithEmailAndPassword for logging in. The IdToken is passed back to the client and stored in localstorage. Authentication and state persistence then relies on the client checking if the current date is past the expiry of the JWT token. API calls to the back end cloud functions also require an Authorization header using 'Bearer {IdToken}'.
This structure is causing me lots of headaches. I've done lots of reading and my current understanding is that firebase has it's own authorization persistence (?) that I can implement directly on my front end. Then using a listener I can automatically get new Id tokens on auth state change. This would solve my problem of the tokens expiring every hour. From what I've read local storage of the tokens is also a security risk.
I'm unsure as to how that affects authorization of my function calls. Should I still use the authorization header or is there a more elegant firebase way of doing that?
If you use Firebase Authentication's built-in providers, they indeed automatically persist the sign-in information information on most clients, restore it upon restart, and refresh the ID token just before it expires.
So if you use one of the standard providers, you can just get the user's ID token and then pass that to your Cloud Function.
You can even skip that step by using Callable Cloud Functions. For those, the Firebase Functions SDK passes the ID token along automatically, and the server automatically decodes and verifies it, and passes it to your code as context.auth.
I haven't seen any examples of this, but I want to purely interact with Firebase through the backend, and not the frontend with Javascript.
I have auth tokens being minted on my Go backend when a new user is added and then these users are written into a mongo database.
What I want is to be able to get a messaging token for my users, and then add it to their user document in mongo, that'll be used to send messages through the backend.
The reasoning is that we don't want to have to communicate with Firebase on our frontend.
Is this even possible?
If you want to send a message directly to a device with Firebase Cloud Messaging, you will definitely need some information from the client. There is no avoiding following the setup instructions on the client. In particular, you will have to handle the registration token on the client and send it to your backend so it can send the messages.
The Firebase Authentication token will not be useful to you at all for sending messages. FCM doesn't send messages to users - it sends messages to devices (or topics). You will have to figure out for yourself which devices belong to which users.
What is the difference between the newly release ASP.NET WebHooks and Signal-R? What are the advantages or disadvantages? What are the use cases for each technology?
SignalR is for notification within an ASP.NET app using WebSockets. You can exchange event notifications through WebSockets, however it requires a constant network connection.
WebHooks are for event notification across other web applications and other external services. (Think B2B communication). For instance, you can receive a WebHook when someone sends you money to your PayPal account. PayPal fires off a POST request to your predefined URL handler and then your app does something with that notification. You pre-configure everything on the PayPal side first. You also set up an application to handle the incoming POST request. The event notification is "pushed" to you in (near) real-time. No need to hold open a network connection while waiting for events.
The two can be complementary. For example, when you receive the WebHook from PayPal, you can notify a logged in user on your webapp (using SignalR/WebSockets) that money has been received successfully.
TLDR: Event notification across different web applications
It really depends on service you want to integrate with and how. WebHooks is a simple pattern for integrating event notifications across different SaaS services. If the service you want to integrate with supports WebHooks then you can use that. If it supports SignalR then you can use that. In that sense the two are quite complementary.
Check Henrik F Nielsen post at
http://blogs.msdn.com/b/webdev/archive/2015/09/04/introducing-microsoft-asp-net-webhooks-preview.aspx