I have an app where i want to implement a chat/messaging service. I have to use CouchDB with PouchDB. My problem is that every user should be able to send a message to anyone, but only the receiver of the message can read this, but there is no way in CouchDB to restrict every user from reading the conversation doc. Database per user is also not a solution since there is no way for everyone to write to the corresponding database.
CouchDB & PouchDB do not have per-document access control, only per-database. One solution to this is to have:
a single database for sent messages residing on the server. The PouchDB clients write (but don't read) to this database by doing client->server one-way replication.
a database per user on the server side with server->client one-way replication. This is how the PouchDB clients get received messages.
on the server side, write some custom script to move documents from the central database to the per-user databases depending on the recipient
This is a similar approach to the one outlined in my blog post about bus station displays which uses a serverless changes feed listener to route the messages. It's not ideal, but is one solution.
Related
I would like to create a messaging app that will be available both on website and mobile ie users can access there messages with their account both on the website and the app.
Now, the issue is that in order to keep the history of the messages I must save them somehow in the database. I do not want to save them in plain text to avoid any data stealing (the app might go in production someday). But, I do not see any way to save the messages encrypted in the database and decrypt them for both the sender and receiver.
What I thought about doing is to create two instances of each message sent in the db. One being encrypted with the sender's public key and the other one being encrypted with the receiver's public key. This way both sender and receiver will be able to decrypt every single message saved in the discussion with their private key.
However, I do not if this is the best way of doing it, what do you think about? Also, I guess the private key will be stored on the user's device but what would happen if the user deletes the app or changes device. Furthemore what about the website? How will it access the private key if it is on the user's mobile device?
Fyi I am using NodeJS, MongoDB, React, React Native and Socket.io
I have an android app on which I want to send notification via my web app.
How do I send Firebase Cloud Messaging notification with nodejs? I have found a lot of examples and posts on this subject, but in all of them you are supposed to just paste device Token and send notification to that device. If I wanted to use it that way, I would be able to simply implement this from official documentation.
The thing is, I need to receive user id from database so I know which user I want to send notification. After I have user id I can then retrieve device Token from the same database. I get both user id and device token on client side. And documentation refers to server side.
This all happen after button click. So, I don't understand how to send notification on server side, meaning, I don't have there all those informations I need - user id, device token and message info that contain some other database info. Do I pass those arguments from client side to server side somehow, or is there a way of using modules like "require()" on client side?
What is the best approach here?
You will need to implement a device token registry to fit with your use case. So if you want to send messages to users, then you will need a registry (really just a fancy word for a database) of the token(s) for each user. Then when you want to send a specific user a message, you look up their token(s) in the registry, and call the FCM API to send messages to them. Since you mention Node.js, you can likely do this using the Firebase Admin SDK: https://firebase.google.com/docs/cloud-messaging/admin/send-messages#send_to_individual_devices.
An alternative I have once written article about using a topic for each user, which saves having to have a registry of their tokens. While this is less secure (since anyone who knows a topic, can subscribe to it), it is definitely easier to implement.
I have a Firebase mobile application that serves many users.
The application requires to send email notifications to users. Firebase cannot send functional email.
Zapier is not an option as the webhook service is very limited and cant consume complex JSON such as the email body.
To solve this, I store the “email job” in the Firebase database (include To, subject and body”), I setup a “mail server” using nodejs server (at home) that listen to the Firebase database, so whenever there is a “new email job” it sends the mail and mark the job status to “DONE”.
In order to maintain high availability and scalability, I must be able to run more than one “mail servers” but this will cause duplication mail as all servers will listen to jobs.
I cannot address a job to a specific server, as the server may be down and I will lose jobs. Also, Firebase does not have kind of SELECT FOR UPDATE as SQL databases have to maintain concurrency.
Is there a way to solve this issue using Firebase? If no, any workaround?
All of Sails' publish methods take an extra parameter which allows me to tell Sails not to publish to one specific socket. What I'm not seeing is a way to restrict a whole class of sockets from receiving updates.
In my application, users manage a lot of personal information including things like names and addresses. When a person record is created or updated, I don't want that information broadcast to every single socket connected to the system. The only users who should receive the updates are users associated with the group that owns the record in question.
I need to be able to:
Review the session associated with each socket.
Determine if the user associated with that socket is a member of the group that owns the created/modified person record.
Only publish to the sockets that fit said criteria.
Does Sails support filtering on the server side? If that kind of filtering is left up to the client, then I can't secure my data.
I want to have a activemq broker(or a cluster). I would like to have multiple queues in it. I would like to give access to say a particular queue only to a particular client and no other client. IOW I don't want one client to be able to access the queue meant for another client. How can I secure the queues?
You'll want to use either the JAAS or Simple Authentication Plugin.. Either of these will allow you to set up authorization to queues.