I am making a React app with Nodejs in the backend with Mongoose/MongoDB. I have some data that I would like the user to be able to update. Let´s say for example, a Wikipedia article. However, when the user submits the update, I want to keep showing the old data until the new data has been verified.
Does MongoDB have some mechanism to help with this situation? Or do I have to make the whole mechanism? Kind of having two schemas, "DataSchema" and "DataSchemaProposal", then the user would submit a DataSchemaProposal and somehow implement the mechanism to replace DataSchema data with the proposal when the proposal is accepted.
Related
In my app users can read and write data on Firestore.
In the Firestore Database there Is also a "Credit" document for each user where the balance of coins Is stored.
How can I be sure that no One could modify an APK of the app in order to change the balance?
In the app there are some functions that remove some coins from the balance, my fear Is that someone could change the code and add coins instead.
assuming that your app implements firebase authentication to authenticate operations on firestore it's safe to say that your app is compiled with a key and it has an hash.. it's not possible to someone to decompile the app, change the code and recompile it with your key.. so the new "hacked" app will have a different key and hash and firebase authentication will not work and your db will be safe
I think you need to secure the data itself. In your scenario I don't think you can have code in the app that simply writes a value to the balance. You need to create a separate API or firebase function to secure what you are trying to do.
If you want to ensure that only your application code can call Firestore, consider enabling Firebase App Check.
Just keep in mind that:
Using App Check does not guarantee the elimination of all abuse
So you'll want to combine it with other security measures, for example through the server-side security rules that Firebase also offers for Firestore.
Also see:
Locking down Firebase DB access to specific apps
How to allow only my app to access firebase without a login?
We already have DB with users.
We have to migrate all records to Keycloak DB or we can just implement Storage SPI ?
We don't want to migrate records, because we should also support old DB, it brings problems because we will need synchronize 2 DB.
Can you please write what could be the problems in this approach and write your advices for resolve theirs ?
USER DATA SOURCES
Moving to a system such as Keycloak will require an architectural design on how to manage user fields. Some user fields will need migrating to an identity database managed by Keycloak. Applications can then receive updates to these fields within tokens.
KEYCLOAK DATA
Keycloak will expect to have its own user account storage, and this is where each user's subject claim will originate from. If a new user signs up, the user will be created here before being created in your business data.
Keycloak user data will include fields such as name and email if they are sent in forgot password workflows. You can keep most other user fields in your business data if you prefer.
So to summarize, a migration will be needed, but you don't have to migrate all user fields.
BUSINESS DATA
This may include other user fields that you want to keep where they are, but also include in access tokens and use for authorization in APIs. Examples are values like roles, permissions, tenant ID, partner ID, supscription level.
DESIGN STEPS
My recent blog post walks through some examples and suggests a way to think through your end-to-end flows. There are a couple of different user data scenarios mentioned there.
It is worth doing a day or two of sketching out how you want your system to work. In particular how your APIs will authorize requests, and how you will manage both existing and new users. This avoids the potential for finding expensive problems later.
Using the firebase platform..
I would like to save some custom information about a user once they register.. and just for examples sake, lets say his/her favorite color.
So far when I register a user this is the only meta data I get
What options are at my disposal to get this done?
You have two options:
1 - Use Custom Claims
You can save additional data to the access token of the user. You can read that data directly from the user in the frontend and also in all database rules. I would recommend to use this for basic auth data like isAdmin or isRole if there are not much data to save. The reason for that is that it's quite limited in the amount of data you can save. Because it's saved in the token it has to be small so you should not save to much in it. You can find more about it here. You should edit this fields by a firebae cloud function using the admin sdk.
2 - Use one of the databases
I see it very often and it's quite common in Firebase to store such additional user data into one of the Firebase databases. You can make those 1000% securely by allowing only the user to write and read then or only to read depending on your needs. If you want to save more than just simple data I would recommend this. One reason more is if any other user like admin needs that data from another user you would not be able to get it by using the first option. It is also much easier to do it when the user needs to save data for himself and by himself. With the first version you would always need to involve cloud functions.
I very often use combination of both where I save such data like isAdmin to the custom claims but all other like nickname or some settings like language to a database. With the database I can also make it very easy to search through all users when you are an admin.
I want to create an app with IONIC to manage buildings. A user can hold multiple buildings. Each building has rooms. Each rooms has logs. Each user is a member of a cooperation.
For many years I've used LAMP. Now moving to mobile and made some IONIC apps. With 2 apps I've used sqlLite as datastore on the mobile device.
But now I've read up on couchDB and pouchDB and really like the concept and the sync option. So now I'm looking into this to use as my datastore (on the mobile and also on the backend).
Now I've got 2 major questions/concerns:
1) Authentication
In my LAMP situation, I usually have an SESSION (table which holds the sessions strings and userID) and an USERS table.
When the user logs in, the user is lookup in the USERS table, and a session string is created and saved with the userID.
Now each time a request is made to the server (for example update data), the session string is also supplied and matched to the SESSION table and retrieve the correct user. From that point on, I can validate if the post is valid and the data also belongs to the correct user.
Back to couchDB, I know there is a cookie management in couchDB (http://guide.couchdb.org/editions/1/en/security.html).
So here I can validate if an user exists and validate the credentials. Now the app can send requests with a cookie.
2) Fetch/Update the right data
In my LAMP situation, I always knew which data belongs to which user. And the back end always checks if this is correct.
In my couchDB I want to create database and each document is an user with all the data.
So now here comes the problem. I can validate an user in couchDB, put there's no way to validate the data (at least as far I know of) that it belongs to the right user.
My goal is that the mobile device syncs the document to the couchDB server.
3) Database structure
At first I wanted to create a database per user. But this is not scalable. Also an user is an member of a cooperation. I also need to generate reports per cooperation/user.
So now I was thinking to create a database per cooperation. But now the problem is, when a user login, I need to know wich database to connect to lookup the user data.
Now I want to use 1 database and each document is an user and holds al data (buildings/logs).
Has anybody got some other suggestions/resources on this approach?
You can try couchdb in combination with superlogin:
SuperLogin is a full-featured NodeJS/Express user authentication solution for APIs and Single Page Apps (SPA) using CouchDB or Cloudant.
github
Tutorial
I am writing an ERM application using the Zend Framework in which user accounts are created under a main company account, enabling me to limit the number of user accounts for a company based on the license which the company paid for. Each company account has its own database (with identical structure to other companies) on my server to store data relevant to that company. The name of each companies database is stored in my "back end" database along with the rest of the companies account information and license key. The authentication system works as follows:
A new user (having never used the application before) lands on the index page and is greeted by a single text field for "Company Account Number"
After clicking "Submit", the next step in authentication is for username and password. When the user submits this form, all three pieces of information (account number, user name and password) are sent to my application's Authentication handler.
My "back end" database which stores company accounts is first queried to see if the account entered by the user exists. If it does, the company_db_name column is returned and a connection established then saved in the Zend_Registry. Otherwise, authentication has failed.
If the company account does exist, the database that was returned then has its users table queried for the specified username and password hash which either returns a successful instance of MyApp_Auth or false if the credentials were incorrect.
At first, I planned on storing user session data in the individual companies database, however I have run into the problem that there is no connection to this database when first landing on the application's index page. I have planned a workaround as follows:
Move my session storage table out of the customer's database to my "backend" database, which has a connection as soon as the application launches.
Add a "company account number" column to the table and index this column.
When a user lands on the application index page, the backend database can then be queried for the current user agent's sessionid. If it is found, then return all the necessary information i.e. the company database name to establish a connection, and the user's information to build a model with.
I have a couple questions regarding this approach:
Question 1 : Is there any risk in storing all session information for every user of my application in a single back-end database table? I am thinking in the multi-thousand user mindset.
Question 2 : I am concerned that a new user may visit the index page and by complete chance (understanding that this is a very low possibility, but still possible) have the same session_id as an existing session in the back-end database. Is this a valid concern, and if so, can it be mitigated?
Question 3 : Is there a better way, or would you recommend a different method to achieve my required functionality?
Thank you for your time!
To answer your 3 questions:
Answer 1. The is not risk as such for the storing session information of every user as long as you remove it on session expiration. The issue here is "scalability" what approach are you using? Is it scalable enough? What is the write/read speed? MySQL is 'structured' approach just like MSSQL. What processing time are you looking for? How much of information is stored? What is the architectural studies. Is it feasible enough for your client?
Answer 2. Ideally the session_id will not be the same so that should not be your concern.
Answer 3. You need NoSQL (Not Only SQL but, even more) approach. Read this
Looking at the MASSIVE-ness of your data, I strongly suggest you to go for HBASE (uses Hadoop, easy for multi cluster) or CouchDB or if you are Amazon fan dynamoDB.
Questions? :)
EDIT: Just realized you are using Zend Framework. In that case, you can also use MongoDB, and use Shanty Mongo library.