So just started playing with Meteor and trying to get my head around the security model. It seems there's two ways to modify data.
The Meteor.call way which seems pretty standard - pretty much just a call to the server with its own set of business rules implemented.
Then there is the Collection.allow method which seems much more different to anything I've done before. So it seems that if you put an collection.allow, you're saying that the client can make any write operation to that collection as long as it can get past the validations in its allow function.
That makes me feel uneasy cause it's feels like a lot of freedom and my allow function would need to be pretty long to make sure it's locked down securely enough.
For instance, mongodb has no schema, so you'd have to basically have a rule that defines which fields would be accepted and the format those fields must be in.
Wouldn't you also have to put in the business logic for every type of update that might be made to your system.
So say, I had a SoccerTeam collection. There may be several situations I may need to make a change, like if I'm adding or removing a player, changing the team name, team status has changed etc.
It seems to me that you'd have to put everything into this one massive function. It just sounds like a radical idea, but it seems Meteor.call methods would just be a lot simpler.
Am I thinking about this in the wrong manner (or for the wrong use case?) Does anyone have any example of how they can structure an allow or deny function with a list of what I may need to check in my allow function to make my collection secure?
You are following the same line of reasoning I used in deciding how to handle data mutations when building Edthena. Out of the box, meteor provides you with the tools to make a simple tradeoff:
Do I trust the client and get a more responsive UI (latency compensation)? Or do I require strict control over data validation, but force the client to wait for an update?
I went with the latter, and exclusively used method calls for a few reasons:
I sleep better a night knowing there exists exactly one way to update each of my collections.
I found that some of my updates required side effects that only made sense to execute on the server (e.g. making denormalized updates to other collections).
At present, there isn't a clear benefit to latency compensation for our app. We found the delay for most writes was inconsequential to the user experience.
allow and deny rules are weak tools. They are essentially only good for validating ownership and other simple checks.
At the time when we first released to production (August 2013) this seemed like a radical conclusion. The meteor docs, the API, and the demos highlight the use of client-side writes, so I wasn't entirely sure I had made the right decision. A couple of months later I had my first opportunity to sit down with several of the meteor core devs - this is a summary of their reaction to my design choices:
This seems like a rational approach. Latency compensation is really useful in some contexts like mobile apps, and games, but may not be worth it for all web apps. It also makes for cool demos.
So there you have it. As of this writing, my advice for production apps would be to use client-side updates where you really need the speed, but you shouldn't feel like you are doing something wrong by making heavy use of methods.
As for the future, I'd imagine that post-1.0 we'll start to see things like built-in schema enforcement on both the client and server which will go a long way towards resolving my concerns. I see Collection2 as a significant first step in that direction, but I haven't tried it yet in any meaningful way.
stubs
A logical follow-up question is "Why not use stubs?". I spent some time investigating this but reached the conclusion that method stubbing wasn't useful to our project for the following reasons:
I like to keep my server code on the server. Stubbing requires that I either ship all of my model code to the client or selectively repeat parts of it again. In a large app, I don't see that as practical.
I found the the overhead required to separate out what may or may not run on the client to be a maintenance challenge.
In order for the stub to do anything other than reject a database mutation, you'd need to have an allow rule in place - otherwise you'd end up with a lot of UI flicker (the client allows the write but the server immediately invalidates it). But having an allow rule defeats the whole point, because a user could still write to the db from the console.
The usual allow methods I have are these:
MyCollection.allow({
insert: false
update: false
remove: false
})
And then, I have methods which take care of all insertions. These methods perform the type checks and permission assessment. I have found that to be a much more maintainable method: completely decoupling the data layer from the code which runs on the client.
For instance, mongodb has no schema, so you'd have to basically have a rule that defines which fields would be accepted and the format those fields must be in.
Take a look at Collection2. They support schema checking at run-time before inserting documents into the Collection.
Related
From my experience, keeping backend DB and the frontend state tree in sync becomes a non-trivial task as the app grows more complicated.
For example, when you create a new Post in a blog, you have to create an object in the DB as well as attach a post object in your state tree (ex. inside posts reducer). It gets more complicated if the state tree is nested. If you update a comment that belongs to a post, you have to find the right post in the state tree, and find the right comment and update.
I understand why having an App State Tree is beneficial but this syncing causes too much overhead for me to truly appreciate Redux.
Q. Is there a way to do this syncing more easily?
Meteor is specifically designed to solve the problem you're mentioning.
Redux is only to manage state on the client. More precisely, its job is to hold the state needed for the ui itself.
It's often used with React where it functions as a smart place to stash anything and everything needed to render the ui. This often includes a complicated state and may include a lot of app data. It may then start to look more like a database, but databases have a number of properties that Redux lacks. Persistence comes to mind...
Meteor is a framework and Redux is not. As such, Meteor comes with an enormous amount of buy-in where Meteor decides on how to deal with a large number of issues in your app. Redux on the other hand is very permissive. It doesn't decide on what your state looks like, or how you talk to your backend, or how you render your ui.
So inasmuch as Redux allows you the freedom to decide for yourself how to deal with these issues, it also leaves you with the responsibility to do so. Redux is super tiny and you should only expect rock solid state management, and nothing more.
How much of your global app state you move to the client is entirely up to you, and how you connect it to your backend, and if this backend runs node.js+Mongo or php+mysql or lisp+text files is entirely up to you. The same can not be said when using Meteor.
With great power comes great responsibility.
I have the same question and I'm sure there's a tried-and-true correct response to this. However, I brainstormed two possible solutions:
1) add the post to the app state 'manually', then the next time a GET is requested, reconcile the state and the response (your strategy). This is a lot easier if your client state is normalized
2) do a GET immediately after the POST status is 200, and deal with the latency with an activity indicator.
The accepted answer to me , is not a fundamental explanation.
I'm looking for suggestions regarding implementing process flow / work flow management in a PureMVC based application.
Our Flex application includes a number of processes such as account creation, payment processing, etc.
Within our team, there is some discussion of how rigidly we should adhere to the PureMVC model.
Within the PureMVC model, it seems reasonable that the current state in the process could be managed in a Proxy.
Commands are clearly responsible for processing the actions required of each node and for node transitions.
Mediators for managing the UI.
However, I think that there is an important bit still missing here: a ProcessController.
The approaches we've reviewed all seem to either violate the PureMVC model (even just slightly) or make unreadable code.
A proxy would maintain the state of the process. As such, it seems to be an appropriate way to implement the controller. However, this is putting a lot of business logic into the proxy.
The Mediator space makes more sense, but the controller in that space would not necessarily directly interact with any particular UI element but would instead coordinate/delegate to dedicated Mediators.
Yet another model would have us put process transition information into Commands. While this seems to be the best place for that work (given the role of commands relative to proxies and mediators), this approach looks to make some particularly heinous looking code with process transition logic distributed among scores of commands.
So how have others handled this problem?
Thank
Curtis
This is exactly the problem that PureMVC StateMachine Utility (and Finite State Machines in general) are meant to solve.
In a simple XML format, you can define states, valid transitions to other states, and the actions that trigger those transitions.
It is all notification-based, so you send StateMachine.ACTION notifications that cause the StateMachine to execute any entering/exiting guard logic that may be necessary (e.g., only allow exiting the FORM_ENTRY state if all the data valid, or only allow entry into the FORM_PROCESSING state if the user has admin rights, etc.). If a state change occurs, notifications are sent that can be used to organize the view or execute logic upon entering the new state.
Here is a StateMachine Overview presentation that will give you a better idea
http://puremvc.tv/#P003/
I think your idea of 'ProcessController' is probably the better way of doing it. Personally, I'm not a fan of PureMVC and don't use it because it doesn't allow enough flexibility or extension points to help with such problems.
Frankly, it's hard to advise on your issue because I don't know exactly what you're trying to accomplish. I do agree that the concern needs to be handled by one object. If you can, try to create a model that can store the data for the process and have another class just manage it throughout. Not sure if that makes sense, but then again, your problem isn't very clear either.
As an added extra, I would look into Dependency Injection. I'm trying to remember if PureMVC does it (I don't think it does), but with DI it would of been a fairly simple problem to solve. Frameworks like Parsley and Robotlegs are really good at that.
In pureMVC the State Machine Utility is probably the best choice for a process controller - and btw, according to the Implementation Idioms & best Practices doc. for PureMVC, it's perfectly fine to have mediators that don't manage a visible component
I have what I consider to be a fairly simple application. A service returns some data based on another piece of data. A simple example, given a state name, the service returns the capital city.
All the data resides in a SQL Server 2008 database. The majority of this "static" data will rarely change. It will occassionally need to be updated and, when it does, I have no problem restarting the application to refresh the cache, if implemented.
Some data, which is more "dynamic", will be kept in the same database. This data includes contacts, statistics, etc. and will change more frequently (anywhere from hourly to daily to weekly). This data will be linked to the static data above via foreign keys (just like a SQL JOIN).
My question is, what exactly am I trying to implement here ? and how do I get started doing it ? I know the static data will be cached but I don't know where to start with that. I tried searching but came up with so much stuff and I'm not sure where to start. Recommendations for tutorials would also be appreciated.
You don't need to cache anything until you have a performance problem. Until you have a noticeable problem and have measured your application tiers to determine your database is in fact a bottleneck, which it rarely is, then start looking into caching data. It is always a tradeoff, memory vs CPU vs real time data availability. There is no reason to make your application more complicated than it needs to be just because.
An extremely simple 'win' here (I assume you're using WCF here) would be to use the declarative attribute-based caching mechanism built into the framework. It's easy to set up and manage, but you need to analyze your usage scenarios to make sure it's applied at the right locations to really benefit from it. This article is a good starting point.
Beyond that, I'd recommend looking into one of the many WCF books that deal with higher-level concepts like caching and try to figure out if their implementation patterns are applicable to your design.
I'm building the standard 3-tier ASP.NET web application but I'm struggling as to where to do certain things - specifically handling exceptions.
I've tried to have a look around on the web for some examples but can't find any which go as far as a whole project showing how everything links together.
In my data-tier I'm connecting to SQL Server and doing some stuff. I know I need to catch exceptions that could be raised as a result but I'm not sure where to do it.
From what I've read I should be doing it in the UI tier but in that case I'm not sure how to ensure that the connection to the database is closed. Is anyone able to clarify how to do this? Also if anyone knows as to where I could find an example 3-tier web application that follows best practices that would be great too.
thanks
There are no easy answers or patterns that will ensure success. Just like your validation strategy, your exact exception-handling strategy is specific to your exact situation, and is often a trade-off between time and comprehensiveness. There is some good advice we can give though:
Don't ever hide the stack-trace; don't ever use "Rethrow" unless for security purposes you want to hide what happened.
Don't feel you need error handling everywhere. By default, in your lower tiers, letting the actual error percolate up to the top tier is not bad. The UI/Controller is where you have to really decide how to react to something going wrong.
At every point, as yourself what exactly you want to happen if something goes wrong. Often, you won't be able to think of anything better than to just let it go up to the top layer or even to the client machine. (though in production turn of verbose reporting.) If this is the case, just let it go.
Make sure you dispose of unmanaged resources (Anything that implements IDisposable.) Your data access is a great example. Either (A) Call .Dispose() for your (especially) connection, command, datareader etc. in the Finally block, or (B) use the Using Syntax/Pattern which makes sure that proper Disposing happens.
Look for places where errors are likely and where you can look for certain errors, react (by retrying, waiting a second retrying, trying that action a different way, etc.) and then hopefully succeed. Much of your exception handling is to make success happen, not just to report failures well.
In data layer, you must consider what to do if something goes wrong in the middle of a multi-step process. You can let the actual error percolate up, but this layer must handle tidying things up after an error. You'll sometimes want to use transactions.
In an asynchronous situation (either (A.) because of multiple threads or (B.) because business logic is processes separately on "task machines" and such and acted upon later), you in particular need to have a plan for logging errors.
I'd rather see "error handling code" in 25% of your app than 100%. 100% means you probably wanted it to look and feel like you have error handling. 25% means you spent time handling exceptions where they really needed to be handled.
Just a side point that may steer your thinking: if you have any type of volume that may result in concurrency issues (deadlocks) you will want your application to detect that particular SQL error and retry the operation (e.g. transaction). That argues for some exception handling at either the data or business tiers.
-Krip
I believe its best practice to handle exceptions at the last responsible moment. This usually means at the UI level (i.e., the Controller in a MVC app or in the codebehind in a traditional asp.net app). Its at this high level that your code "knows" what the user is asking, and what needs to be done if something doesn't work.
Handling exceptions lower down in the call stack usually results in calling code not being able to handle exceptional situations properly.
In your data tier, you would use the standard patterns (e.g., the using statement for IDisposables such as the SqlConnection), document exceptions you know may occur (don't do this for out of memory or other rare cases), and then let them flow up the call stack when they do. At the most you might want to catch those exceptions and wrap them in a single exception type, in situations where MANY exceptions may have to be handled by callers.
If you need to "clean up" stuff before letting exceptions go, you can always use a finally block to clean up. You don't have to catch in order to use a finally block.
I don't know of any examples of small websites which are designed to highlight proper exception handling, sorry.
This is not a specific answer to your question but if you are interested in best practices I would look at Microsoft Patterns and Practices:
Application Architecture Guide
Web Applications Guides
I know it's possible to use validators to check data input in the presentation layer of an application (e.g. regex, required fields etc.), and to show a message and/or required marker icon. Data validation generally belongs in the business layer. How do I avoid having to maintain two sets of validations on data I am collecting?
EDIT: I know that presentation validation is good, and that it informs the user, and that it's not infallible. The fact remains, does it not, that I am checking effectively the same thing in two places ?
Yes, and no.
It depends on the architecture of your application. We'll assume that you're building an n-tier application, since the vast majority of applications these days tend to follow that model.
Validation in the user interface is designed to provide immediate feedback to the end-user of the system to prevent functionality in the lower tiers from ever executing in the first place with invalid inputs. For example, you wouldn't even want to try to contact the Active Directory server without both a user name and a password to attempt authentication. Validation at this point saves you processing time involved in instantiating an object, setting it up, and making an unnecessary round trip to the server to learn something that you could easily tell through simple data inspection.
Validation in your class libraries is another story. Here, you're validating business rules. While it can be argued that validation in the user interface and validation in the class libraries are the same, I would tend to disagree. Business rule validation tends to be far more complex. Your rules in this case may be more nuanced, and may detect things that cannot be gleaned through the user interface. For example, you may enforce a rule that states that the user may execute a method only after all of a class's properties have been properly initialized, and only if the user is a member of a specific user group. Or, you may specify that an object may be modified only if it has not been modified within the last twenty-four hours. Or, you may simply specify that a string value cannot be null or empty.
In my mind, however, properly designed software uses a common mechanism to enforce DRY (if possible) from both the UI and the class library. In most cases, it is possible. (In many cases, the code is so trivial, it's not worth it.)
I don't think client-side (presentation layer) validation is actual, useful validation; rather, it simply notifies the user of any errors the server-side (business layer) validation will find. I think of it as a user interface component rather than an actual validation utility, and as such, I don't think having both violates DRY.
EDIT: Yes, you are doing the same action, but for entirely different reasons. If your only goal is strict adherence to DRY, then you do not want to do both. However, by doing both, while you may be performing the same action, the results of that action are used for different purposes (actually validating the information vs. notifying the user of a problem) , and therefore, performing the same action twice actually results in useful information each time.
I think having good validations at application layer allows multiple benefits.
1. Facilitates unit testing
2. You can add multiple clients without worrying about data consistency.
UI validation can be used as tool to provide quick response times to the end users.
Each validation layer serves a different purpose. The user interface validation is used to discard the bad input. The business logic validation is used to perform the validation based on business rules.
For UI validation you can use RequiredFieldValidators and other validators available in the ASP.NET framework. For business validation you can create a validation engine that validates the object. This can be accomplished by using the custom attributes.
Here is an article which explains how to create a validation framework using custom attributes:
http://highoncoding.com/Articles/424_Creating_a_Domain_Object_Validation_Framework.aspx
Following up on a comment from Fredrik Mörk as an answer, because I don't think the other answers are quite right, and it's important for the question.
At least in a context where the presentation validation can be bypassed, the presentation validations and business validations are doing completely different things.
The business validations protect the application. The presentation validations protect the time of the user, and that's all. They're just another tool to assist the user in producing valid inputs, assuming that the user is acting in good faith. Presentation validations should not be used to protect the business validations from having to do extra work because they can't be relied upon, so you're really just wasting effort if you try to do that.
Because of this, your business validations and presentation validations can look extremely different. For business validations, depending on the complexity of your application / scope of what you're validating at any given time, it may well be reasonable to expect them to cover all cases, and guarantee that invalid input is impossible.
But presentation validations are a moving target, because user experience is a moving target. You can almost always improve user experience beyond what you already have, so it's a question of diminishing returns and how much effort you want to invest.
So in answer to your question, if you want good presentation validation, you may well end up duplicating certain aspects of business logic - and you may well end up doing more than that. But you are not doing the same thing twice. You've done two things - protected your application from bad-faith actors, and provided assistance to good-faith actors to use your system more easily. In contexts where the presentation layer cannot be relied upon, there is no way to reduce this down so that you only perform a task like "only a number please" once.
It's a matter of perspective. You can think of this as "I'm checking that the input is a number twice", or you can think "I've guaranteed that I'm not getting a number, and I've made sure the user realises as early as possible that they're only supposed to enter a number". That's two things, not one, and I'd strongly recommend that mental approach. It'll help keep the purpose of your two different kinds of validations in mind, which should make your validations better.