I am creating backend for a messaging application. I want it to be mostly a web app so would have to store the list of people with whom a user chats and all the messages in the server. However, I also wanted to have the ability to extend it and use the same backend for a mobile app. So I was thinking of having a separate database or table for every user and only open the connection to it when a user connects to the backend using WebSocket. However, according to this post, it seems that in most cases, it is better to have a single table and have many to one relation. So what would be the best choice in my usage? Also, how can I go about implementing that in Django?
Related
I am developing an app in which user stores their data. I want to add option to allow user to connect their database (on their server) to the django project so that they can store their sensitive information. Eg:-
Data stored on my app database -> Name, Username, Email
Data stored on user database -> Phone, Bank Details etc.
I cannot configure user database credentials in settings.py as it will be dynamic and different for different users.
So, how do i accomplish this?
You can't have different databases for different users. The database is for the site.
In terms of security, people have access to the data you allow them to in the database. So if security is important, just structure the data in such a way that people can store what they need & only access what they're supposed to.
It sounds to me like you need to think about your database design to accomplish what people need, and then ensure the project keeps data restricted to the correct people.
I use sqlalchemy to solve the problem. I also integrated batch script and django views to create tables. If any one has the same issue, i can share the code.
Here is the quick link of sqlalchemy: https://www.sqlalchemy.org/
I am a newbie to Multi-Tenant architecture, developing SaaS product using django-tenant-schema
my requirement was something like clients would register for product. For every registered client, I was creating new schema by following single database and isolated schemas approach. Whenever client requested from a browser I was able to identify them by using subdomain and giving privilege to acces their specfic schema. While I was starting coding lot of questions were popup in my head. I am really sorry for asking here but stackoverflow is only my last hope. Database was like below
Database
Public_Schema
auth_user
Clients_List_Table
ClientA_Schema
auth_user
ClientA_User_List
ClientB_Schema
auth_user
ClientB_User_List
Q1.What kind of admin actions we can perform on every client?
I have rest api for example http://client.example.com/api/user_list/ here client maybe ClientA or ClientB
Q2. How can we implement api routing which gets client name dynamically when user requested at browser which let us to use corresponding schema to display current client's user_list.
I have an application that is run on multiple user systems, and using OAuth, allows the users to log in via Facebook, Twitter, etc. The entire point of the user logging in is to get settings and actions that the same user made while logged in on other computers, as identified by logging in with the same OAuth provider + provider user id. The application itself is written in C++ using Qt.
My question is this: how can I save the settings that a user made, and allow them to retrieve it in a secure way? I have a centralized server that I can store information using MySql tables, but I'm not sure the best way to have the user application prompt the server, and receive the data stored for that user.
Any ideas or places you could point me towards?
There are several ways I could think of with this, all have trade offs:
Generally I would store the data in mysql using some kind of string or object encryption/serialization method. I do not use Qt much but http://qt-project.org/wiki/Simple_encryption has some examples of very simple encryption that could be used.
Then the question becomes: What do you use as the key? I would go either with the key provided by OAuth for that user (which could be an issue if users de-authorize the app but still want access to this data) or some other user provided key (which is counter to using OAuth in the first place).
Another option is to go with Qt Users session http://qt-project.org/doc/qt-4.8/qtwebkit-guide-cache.html
This would maybe remove the need to encrypt since it should only be accessible within the users scope.
NOTE: Based on comments below it seems the issue is more about securing communication with the MySQL versus the data inside of MySQL. Waiting on user comments to revise my answer.
I randomly pick two friends of the user and ask him/her to pick who is the better friend. Now all I have is the friend ID which I then have to use to create a poll and store in the database accordingly. Using the Facebook graph API, I have the ID. All I need to do now is to pass it to Django.
I'm new to this so how exactly would I do that? Pass a javascript variable to Django?
I see two options.
At client side using Javascript SDK,
Fetch the friends' profile details along with ID.
Convert them to JSON.
Do a POST request to a django url/view which stores the data in database.
In this way, you don't need to do any graph API queries further from server side. But this won't help you updating the data at realtime. Consider, if one of the friends changing his name in FB, now what is stored in your database becomes obsolete. So, you need to make sure that some thing from client side implemented to do real time update posts to server side.
At server side using any django facebook graph API apps,
Get the IDs from client side.
Use the fb graph app to fetch the details at server side.
Store them in database.
In this way, you could be able to schedule a callback for real time updates. I prefer the second approach as it's always better to burden the server rather than client. And I found this app simple and do what you need. https://pypi.python.org/pypi/django-facebook-api/0.1.10
Are they any pitfalls to using django session to store user information? in what situations should I avoid using this mechanism?
"The session framework lets you store and retrieve arbitrary data on a per-site-visitor basis", so if you're fine with that (the stored dictionary based information is available only for the specific user of that session, as long as you don't access the selected session backend otherwise) it's perfectly ok.
The only pitfalls I see could be introduced when using a cache-based session backend (cache invalidation, persistence of data, distribution of to-be-cached-data to multiple servers, things like that), specifically when the storage of data is different from your main storage (database) - say with memcached or file based caching.
One thing that surprised me with storing data in the sessions is what happens (or doesn't happen) when the user has the site open in two browsers (say once on their mobile, once on their desktop).
For example, I was having a performance problem and decided to fix it by making fewer hits to the database. The site's premise was that the mobile app was for viewing data but you do changes through the desktop site.
There was some logic like this:
if not session_data then:
fetch_data_and_put_in_session
else:
get_session_data_ftw()
If the user logged in on their mobile the session data was created from the database. If they then used their browser to make changes to the data they couldn't view it on their mobile until their session expired.