Newer developer here. I'm creating a Nodejs application with MongoDB. When do you write user inputs to the database? Is it immediately when they want to perform a CRUD action? Or do you wait until they end their session to update their changes (showing them a "fake" updated view during the meantime)? I would think writing to the database every time would be less than ideal, but I also wouldn't want to make the user think their changes were saved to the database, and then some error occurs where it didn't actually happen. How's this handled in the real world?
The user inputs should be written to the database as soon as the user wants to perform the CRUD operations.
If they are not, and you wait for the user to terminate their session, there may be other parts of the application that try and change the data that was supposed to be updated. Or you may want to take certain action in your application based on the current user data from the database, but your database reflects older data, and your application may behave incorrectly.
One may argue that you can maintain the current state of your application, but in case of backend code, the database should always be your single source of thruth.
This is what's known in the "real world" (as you referred to) as a design decision. It's not something for which there's anything even remotely resembling a rule-of-thumb or a hard-and-fast rule.
Instead, it's important to consider all possible factors relating to this design prior to committing to it:
User expectations - will the users of this application expect that their input is stored immediately? When they click the "Save" button? Do they expect their input to be destroyed?
Data retention - are there requirements to retain user input prior to its formal submission? (This is useful in applications for which
Infrastructure - can the underlying infrastructure handle the increased workload? When this application is scaled, will the infrastructure demands exceed capacity?
Cost/benefit - will the addition of this feature trigger development/testing times that exceed acceptable levels for the benefit the feature provides?
These are just some of the considerations you might have. I'm sure with additional time most people could come up with at least ten more.
Related
I am looking to develop an app that is to be used by a fairly small number of people and which has to store and recall data from a cloud database. Users should have various access levels in that some can create stuff, some just read, others modify, some can do anything etc. Just like you would do on a file system.
I am currently considering Azure (very new to it) and thinking what would be the components involved in the project. Obviously, a mobile app (Xamarin.Forms) would be front end. Some kind of Cosmos DB or another database in the cloud. Blob storage too for the media files created by users. But my main question is how to implement the control of what user can do what actions to which data.
A simple way would be to do it within the app itself, but that is counter intuitive and a security risk. Even though this is internal app used by people in the same or sister organizations, it really sounds bad.
Best option would be if that's handled by database itself, but I am not aware of existence of such mechanism. Hopefully, this actually exists and someone will point me in the right direction.
Only other way I see is having some kind of mid layer, still on the back end but just before database. However that also seems clunky and am also unaware of how to even implement it "in cloud".
What would be my actual options?
To clarify, it's about having permissions assigned based on certain columns of a table, for example, and not about having different tables with different user that share parts of data.
That's why it is "Architecture decisions" question, and not "how do i give read permissions to user X of my database Y".
An answer might be "Database X" has what you want. Or, least favourably, "There's no way to offload that to DB. You will have to keep all data separately, so that users can only operate on their set of data, and then collate stuff on the backend". Or something in between, perhaps.
I'm not knowledgeable with Azure or any of that other stuff, but every DBMS will have user accounts that enable different permissions, eg for Apache Derby, MySQL, etc.
I would never implement authentication on the client side.
In salesforce, we have a scenario, on the trigger of the lead object we are updating some records of Campaign. But the user on the behalf of we are running the trigger does not have edit permissions on the campaign. We are not facing any issue in the update of the campaign because the trigger is running the operation in system mode.
Further, we have applied for the security review and made the changes and added the check of the object isUpdatable() and after it, we are not able to update the campaign due to that check which returns false for isUpdatable().
My questions are, Can we pass the security review without applying that isUpdatable() check? if our process has the business logic to update the campaign/opportunity on the behalf of the user who doesn't have permissions on the campaign/opportunity?
If we can not pass the security review with that check then what could be an alternative for it, where one user who doesn't have permission on campaign/opportunity, performs some operation on lead/contact and we want to update the campaign/opportunity in system mode after that operation?
or is it necessary to provide the permissions of campaign/opportunity to that user?
It's not a coding question as such so it might be closed here. Consider cross-posting to https://salesforce.stackexchange.com/
Generally speaking, your app should be simplifying Salesforce. Adding value by being pre-built, pre-tested use case for this customer and saving clicks for the end user. (let's ignore situations like pulling data from other systems, runinng some crazy Excel file generation that SF can't do easily). With that philosophy - you're supposed to respect the System Administrator's wishes when it comes to security. If admin didn't grant Profile X edit access to field Y - the security review answer is that you should detect it. If you can recover gracefully and continue with your program - cool. If it's critical field - throw an error, force the admin to make conscious decision. Because if you're saving clicks - user would face same problem in normal UI. It's not only "describes", it's also about "without sharing" for example.
There's another layer to it - licensing. In the old days "Marketing User" (to access campaigns) was a separate license, you assigned it by clicking checkbox on User but it had to be purchased. Now it's bit simpler, part of the full user license (I think). But there are still situations where you can't access Opportunities for example (Platform License) or can access only Account, Contact and 10 custom objects (Chatter Plus License or whatever is the new name).
If you abuse system mode to fetch data from objects user is not allowed to see (or save to them) - official answer is that SF loses money because of you. Permission should really be assigned and if needed - license purchased. I'm not a lawyer, I don't know who violates the Master Service Agreement with Salesforce, you or the client that installed the app or both. I'd say read the contracts and see what you can do to protect yourself. If that means your app can't be installed by customers on Essentials/Professional (or it can be installed anywhere but can be used only by full users, not by Platform/Chatter/Community) - well, it is what it is. Decide pros and cons, legal consequences if it gets caught...
They're humans, talk with them. Maybe you'll pass review. Better have a rock solid business case why you need to bypass the check though.
P.S. You know you don't have to do describes anymore? Spring'20 goes live this & next week and "WITH SECURITY ENFORCED" and "stripinaccessiblefields" become generally available :)
P.P.S you really need trigger? Workflow, process builder, flow (yuck) - anything to not have code = not need the isAccessible and if it effectively dies on permissions - it's the client's sysadmin's problem?
I'm currently considering CouchDB for a project (still in the research phase). What I want is many users, each with its own database (for authentication purposes), as well as one big read-only database to which they're all replicated, so I can generate reports and make a dashboard. For now let's assume all the databases are running on the same machine and in the same process.
Normally, only a small fraction of the human users will be online and doing things, so I should be able to keep the max_dbs_open setting a lot lower than the total number of users. CouchDB should have no problem determining which ones are idle.
However, I'm worried the extra database will throw a wrench into this. Will having continuous replication from all user databases into the one big database keep them all awake all the time? (And if so, is that bad? Will actually logged-in users lose any priority advantage and get thrashed at bad times?)
Or is CouchDB smart enough to consider a database idle as long as it's not being queried or written to, even if there's an ongoing continuous replication session? Note the replication would only be in one direction: the big database only watches for changes from the user databases.
Suggestions for other ways to approach this problem are also welcome. I'm vaguely aware that if I'm going to have enough to users for this to be a problem, that one database is going to be an unwieldy beast.
Thanks!
Using a node-redux stack. We have action creators on the client side and reducers + redux state on the back end.
I have the following proposal to implement permissions:
Actions are created client side, these may be malicious, even from authenticated users.
Actions are sent to the server.
The request is authenticated server-side and the users permissions ascertained.
The actions pass through the redux middleware which lives inside the node server.
Middleware checks the users permissions against permission specified for the action type.
If the user has the correct permissions for the action then the reducers create a new redux state (which also lives on the server).
Problem:
Each action type is coupled to a set of permissions, this means that we need to take great care creating our reducers so that we never allow an action to do more than it should. With multiple devs on the team and a large application I am not convinced this is sufficient.
Questions:
Is there a good resource/link with a good discussion on handling permissions with redux.
Is redux sufficient for handling complex permissions?
If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?
Redux is "permission agnostic". Redux is just a framework for coordinating actions that update the application state; it contains no opinions or recommendations on how to approach permitting those actions.
Answers
Is there a good resource/link with a good discussion on handling permissions with
redux.
Here is one.
Authorization is a very difficult thing to make general proclamations about, since it very much depends on the business needs. Are you using roles? Are you just requiring authentication? Can users have multiple roles, or just one? How do multiple roles interact? These are not questions with one answer.
Is redux sufficient for handling complex permissions?
This is like asking if JavaScript is sufficient for handling complex permissions. It doesn't really make sense.
From one perspective, is it "possible" to handle complex permissions: yes. Redux will not restrict any permissions scheme you wish to implement at the action level, since actions are just functions that call dispatch (another function). You can use actions to stop the dispatch call for any reason.
From another perspetive, does redux provide an out-of-the-box mechanism that can handle complex permissions without any additional patterns or tools: no. Redux does not even attempt to address this concern, it is entirely up to you.
If we check permissions as outlined above are there any problems that I have not mentioned and is there a better way of approaching this while still using redux?
There are most certainly problems you have not mentioned, since you have not completely outlined your implementation. As they say, the devil is in the details. How you accomplish what you have described will determine what other problems you encounter.
Is there a better way? "Better" is about as vague as you can get. What are your parameters for "better"? In a trade-off between development speed and run-time performance, which would you prefer? In a trade-off between number of server calls and permission granularity, which would you prefer?
All you have said is that you are checking actions on the server. Without knowing what your authorization model is, its impossible to say if a better way exists, even when you precisely define "better", because we don't know what you are doing.
However, given the information you have, and assuming that doing the check server side is both necessary and time-saving (another big assumption), I would say (as weakly as I possible can) yes, there will be additional problems. To name a few:
Latency. Redux expects the entire app state, including the value of input fields. Your model checks the server on each action, so developing in a stricly redux manner every keystroke will go to the server to ensure that it is allowed to update the input. This will make user interaction very slow, and very frustrating.
Bandwidth. This is going to consume a lot of bandwidth, for the reason as above.
CPU. This is going to be very server CPU intensive, for the reason above.
A big win in client-side applications is that the server only does the work it absolutely has to: serving data (in a minimal format like json), and verifying requests to update data. You are going to be taking on the additional work of running all of your clients. This is a questionable tradeoff to reducing the boiler-plate of writing a REST api.
This will also lock you into your action api, and redux. A REST api has the advantage of being client-agnostic. If you change from redux, or just reorganize your actions, the REST api on the server wont need to change (or at least, wont need to change as much). This is going to make refactoring, even if you stick with redux, painful. Whether or not this overcomes the pain of writing a REST api is impossible to say, but its something to consider.
I already audit authorization success, failure and logout.
I've considered auditing (logging) every method call and keeping a version of every row and column that was ever modified, but both of those options will greatly increase the complexity of auditing. Auditing a random subset sees too random.
The legal specs (FISMA, C&A) just say something needs to be audited.
Are there any other non-domain specific auditing strategies I'm forgetting?
Considering that auditing is often about accountability you may wish to log those actions that could contribute to any event where someone/something needs to be accountable..
Alteration of client records
Alteration of configuration
Deletion of Data
It is a good idea to keep some of these things versioned, such that you can roll-back changes to vital data. Adding 'who altered' in the first place is quite straight forward.
Unless someone has direct access to the database, often application logging of any event that affects the database ... such as a transaction altering many tables ... may be sufficient. So long as you can link auditable logical action to a logical unit of accountability, regardless of what subsystem it affects, you should be able to trace accountability.
You should not be logging method calls and database alterations directly, but the business logic that led to those calls and changes, and who used that logic. Some small amount of backend code linking causality between calls/table alterations and some audit-message would be beneficial too (if you have resources).
Think of your application's audit-elements as a tree of events. The root is what you log, for example 'Dave deleted customer record 2938'. Any children of the root can be logged and you can tie it to the root, if it is important to log it as part of the audit event. For example you can assert that some audit event, 'Dave deleted ...' was tied to some billing information also going walkies as part of a constraint or something
But I am not an expert.
I agree with a lot of what Aiden said, but I strongly believe that auditing should be at the database level. Too many databases are accessed with dynamic sql so permissions are at the table level (at least in SQL Server). So the person committing fraud can enter delete or change data at the database bypassing all rules. In a well-designed system only a couple of people (the dba and backup) would have the rights to change audit triggers in prod and thus most people could get caught if they were changing data they were not authorized to change. Auditing through the app would never catch these people. Of course there is almost no way to prevent the dbas from committing fraud if they choose to do so, but someone must have admin rights to the database, so you must be extra careful in choosing such people.
We audit all changes to data, all inserts and all deletes on most tables in our database. This allows for easy backing out of a change as well as providing an audit trail. Depending on what your database stores, you may not need to do that. But I would audit every financial transaction, every personnel transaction, and every transaction having to do with orders, warehousing or anything else that might be subject to criminal activity.
If you really want to know what absolutely must be audited, talk to the people who will be auditing you and ask what they will want to see.