I'm developing a site that has to store a user's contact list. So it will contain people's phone numbers, addresses and also messages sent to this contact. I obviously want to keep this information secure but it seems quite easy an efficient just giving each user a json file with an array of details.
I'm not too sure if this is a horrendously dangerous and insecure idea and if I should be using a table in a database, or something else. Using a table to store messages sent between users doesn't seem too intuitive though. So I was just wanted to know what the most sensible way I would store
i) User specific contact lists with sensitive information
ii) Messages sent between two contacts
I'm sorry if this is a widely known and not even talked about topic. I just couldn't really find a clear answer anywhere.
You should definitely use a database for this. If you store these values on files, then you will have to load all of the information per user every single time you need to access something as small as a single phone number.
Related
I have been trying to make a website as a side project since its summer and I have done a lot of tutorials and research with Firebase and HTML. Now I am stuck on the design aspect. My website requires making use of authentication with email and passwords.
For storing data about the user, what would be the base way to keep the user's data in Firebase database? Create childs named after the user's email, use the UID of the Firebase user, or are their other ways?
TLDR What is the best/recommended way to store a user data in a way that my website can retrieve what it needs when the user logs back on?
The idiomatic way to store user data is in a structure:
users
<uid1>
...
<uid2>
...
This allows quick and efficient lookup of the signed in user.
But you may need additional data for specific use-cases. For example: if you want to ensure that each user has a username that is unique across all users, you'll typically need to add a structure that maps from username to UID:
usernames
<username1>: UID
<username2>: UID
For more on this see one of the many examples: https://www.google.com/search?q=site:stackoverflow.com+firebase+unique+user+name
And for other use-cases you may need yet another structure.
To learn more about NoSQL data modeling in general, I recommend reading NoSQL data modeling. And for Firebase specifically I recommend watching Firebase for SQL developers.
Imagine a user is browsing store flyers on my website and they can press a button on a flyer item to add it to their "list" which will be on another page. I don't really want to require registration to use this list, so how could I store this information? The list could be pretty big, like imagine 200 items. Is it proper to store this information in cookies? I'd imagine cookies aren't meant for this much information? Perhaps there is a way to get a unique identifier for a user? Then I could store their list in my database and retrieve it through their unique identifier. Getting a unique identifier is easy on mobile but for web I imagine it would be a lot more trickier..
I need to set up user permissions within the same table, based on the value of a field. I know that this is not directly possible in Access but a post on Allenbrown.com points to a way of doing this see here. I'm not proficient in coding so I'm hoping that I can get some directions from you. Here are the details:
I have two tables in the database, a parent one populated via a form and a children one populated via a subform. The parent contains companies and the child contain subsidiaries of those companies. In the child table, I have a field called "Domicile" and I want to discriminate user access based on that. Because the database will be used by a variety of people worldwide, my plan is to create user groups based on location and allow users to edit (or add) information based on a match between their location (as specified in the group) and the domicile of the subsidiary. For example, a person in Europe will only be allowed to edit data for subsidiaries that are in Europe, even though companies from other domiciles may be stored in the same table.
I'm looking for some guidance here as well as suggestions as to how you think may be done most effectively. I'm not partial to this method, that's just something I came up with to put some logic behind what I'm doing.
Thank you so much!
The important thing to note in Allen's description is (emphasis mine):
Assuming all updates are performed through forms, the Current event of the form then locks the fields based on this property.
There would be no practical, bulletproof way to prevent users from viewing and altering any data in the table(s) if they open the back-end database file directly.
Since you are asking for advice on how "[row- or column-level restrictions] may be done most effectively" the first issue you need to address is how "effective" those restrictions really need to be:
If you can accept that these will be "soft restrictions" (really a matter of convenience to the user so they don't accidentally alter certain records or fields while using the forms), then Allen's approach might be sufficient. (If so, then follow Allen's instructions as best you can and ask new question if you need help with a specific aspect of that implementation.)
On the other hand, if you need "hard restrictions" (serious protection against mischievous or malevolent user activity) then you'll have to employ a different database back-end -- something like Microsoft SQL Server -- with a richer set of security tools for you to use.
A guy I know asked me to give him the files and dump of my site to see how it works. Are there any stuff inside the Drupal 7 DB that are especially sensitive, like passwords?
It does contain hashed passwords which could make it easier for someone to guess a user's password, as well as personal information such as users' email addresses. It would be best to provide it without the users table.
And that's just the base installation. If you add profile fields, nodes, or anything else with information you want to keep private (for example, if you use the Commerce module then you will have rules with the API access information for your payment provider) then those would be included in the database as well. Finding and removing all of these may not be easy.
I'm trying to learn how to work with twitter api. I'm still a little confused. If I want users to tweet using my input text boxes on my site, do I still need a database for those tweets? Or does the api handle the storage for the tweets?
Thank you!
It is all about your requirement and then your design pattern. Infact You don't need any database to store tweets. In your case where you just want to tweet, You can do it without DB. Infact twitter-rest-api https://dev.twitter.com/docs/api is very good.
If you need to made frequent api call from your app, you can use caching to avoid too many frequent calls. For reference https://github.com/atsiddiqui/ReTweeted
You do not need a database to store the tweets. Twitter stores them.
Once you use the Twitter API to send the tweet data to Twitter.com, it is stored on Twitter.com's storage system. So, it is in a way handled by the api. It does not matter to Twitter whether you stored them in your own database or not.
But it is good practice to store the information in you own server database for record purpose. For example, you might want to know the statistics -- how many users use your service, what is the average use of it.
It may help investigating issues (sometimes legal) like when an user complains that your site published offensive tweet to his account. Then, you can track and check your database.
There are many more cases when you want to see the records in your system.