0

I am building a website with the Flask framework. One functionality of the site will be that users can send messages to each other.

I created a prototype of this using Flask WTF forms. The basic implementation is as follows:

  1. User lands on messaging page and chooses recipient
  2. Javascript detects which recipient the user has chosen
  3. User sends message via form
  4. Form is handled by endpoint
  5. Message is stored on the backend's database

Here are some limitations and considerations I can think of:

  • this system is not "live", i.e.: users have to refresh page to see new messages
  • users can't see if the other user is typing (not a massive deal breaker in my use case)
  • figuring out the recipient with JS could have security violations (?)
  • a massive influx of messages can bring down the whole backend since the messaging system is not decoupled from it
  • notifying users of a new message / marking message as read will have to be done via JS which again could have security implications (?)

As you can see, I am mostly worried about using JS to handle some of this, as I am not very familiar with how to do it in such a way that it can't be maliciously manipulated (e.g.: users attempting to access messages not intended for them / sending messages to users they are not allowed to, etc.)

The other concern is that the system is not decoupled.

After building this prototype, I actually began considering paying for a service like Twilio to handle this part of the website, but I would like to see if I can build it myself.

What other problems might I face and how can I address these concerns?

  • 1
    Reading back on it, I was perhaps being a bit too general. I was mostly looking for feedback from people who have built such systems before; kind of like generic do-s and don't-s when making a simple chat system. – turnip Sep 4 '18 at 14:25
  • 1
    Sorry. Voting to close as too broad. There's no one right or best answer here. It you can break out some individual, objectivity answerable questions, I expect you'll get high quality answers pretty quickly. – svidgen Sep 4 '18 at 14:39
  • I would vote to close for the same reasons. But I can't since it has an open bounty. Just saying in case it counts or matters. – Laiv Sep 6 '18 at 12:39
1
+100

OK, so this is a big topic and not particularly related to Flask.

your problems split up into three areas

  • authenticate the user. Which user is sending this request?
  • authorise the user. Can this user see these messages?
  • push notifications to the user.

Authentication and Authorisation need to be done server side. (looks like Flask has a plugin https://pythonhosted.org/Flask-JWT/)

Push notifications are going to require websockets, (looks like Flask has a plugin:https://flask-socketio.readthedocs.io/en/latest/) and javascript to deal with incoming messages and display them on the page.

Re: separating the chat form the rest of the backend

This isn't too hard you can simply have a separate backend webfarm and url for the chat and have you javascript connect to it.

Your JWT is designed for this kind of cross service request, so that's fine. You may have some CORS requirements, but again, no road blocks.

  • I am using Flask-Login to deal with authentication, but it looks like I need additional setup with Flask-JWT to ensure authorisation . And it looks like Flask-SocketIO will help me with the "live" aspect of this. The only issue now is decoupling this system from the rest of the backend - my thinking is that it is a system which will naturally have a big impact on the backend in terms of requests and storage - any recommendation on how to deal with that? – turnip Sep 4 '18 at 14:13
  • my thinking is that it is a system which will naturally have a big impact on the backend in terms of requests and storage - any recommendation on how to deal with that? Basically, you are asking how to implement a real-time chat application. Distributed and balanced. Far too much than a mere question about security. You have to decide first what kind of chat you need and what features you want. Make requirements gathering first make decisions later (how, when and what to implement). Not otherwise. Chats can be as simple as the one you introduced or as sophisticated as WhatsApp is. – Laiv Sep 4 '18 at 14:29
  • edited to add some stuff about handling the load. As Laiv says though, it's a big topic. I would just dive in and see how you go – Ewan Sep 4 '18 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.