Problem: Our web console shows a list of all computers on which our application is installed. Each machine has some identification information that can be associated with it. Simple strings like department name, team name etc. We need to make it such that the user can change the name of these identification fields and add/remove as many as he wants. How can we best implement this?
Initially i thought that i could implement this as a singleton. In the application start, i could read the last set identity field names from the db and create a singleton instance of a list of strings. This could be passed around to all functions that need to display or access the identity information. The appeal in this option is that if the user changes the identity fields name from the ui or adds or removes the fields, i can simple modify the singleton object and the change will be reflected.
However i feel there must be a better way to achieve what i want. Because there a lot of such information that the user can modify at will and we need to track them.
Any suggestions?
Just use the objects from your ORM to maintain and use this information in the application. Many ORMs have the ability to cache this sort of thing, so it's not like you will lose any speed over it.
I'm not a big fan of using a Singleton to do this. It's hard to unit test, and you'll still have to persist it to the database eventually.
Related
I will develop a new app (Maybe using Laravel or Rails). The point is that we will have our database with let's say user table so at application level, we will have a User model. When User model change, we will send a notification to another external source instantly. In the future the app must allow switch the external source.
I think that a good option is create a UserService (Service layer design patter) class to wrap the logic (keeping data in sync) and then all controllers will use it.
What do you think about it's the best way to do it?
I only have experience with Laravel so I'll be speaking for Laravel.
Laravel provides pretty much this - out of the box. It provides events for Model methods, such as saving, saved, created, creating... So it's extremely easy to set up service-level notifications on any of those events. It's also really easy to define your own events, if you need more specific triggers.
However, since you're doing this on application level, you will need to make sure everything is saved through your application's models. Say, if someone was to edit some data directly through SQL, it would bypass the events. So you need to make sure that everything (for example a mobile app connected to your service) is saved through your application.
Another option would be to use some database that provides that functionality (PostgreSQL out of free ones). But judging by "In the future the app must allow switch the external source." it's exactly what you're trying to avoid.
We have a fairly complicated framework (made up of multiple plugins) that we've developed for all of our future Groovy/Grails applications. One aspect of this framework is the ability to retrieve user information from the various systems that we store this data in. Currently we have three classes that represent a user (one for LDAP (non AD), one for AD, and one for database). The reason for three separate classes is because they access totally disparate systems and are based on different base classes to provide various functionality need to access these systems. There's also dependencies, etc. that require this three class approach. One of these classes (the one for AD) is also used by Spring Security to represent a user. It is also possible to create any user object type from another user object type.
What I'm trying to create is a way for us to cache these objects. For example, during login, one class is always loaded (by Spring Security). However, throughout the process of using the application, another class (for database info for example) might get loaded temporarily. Ideally I'd like to cache these objects (that all represent the same user) so that we don't have to reload information.
In the end what I'm hoping to accomplish, is the ability to pass one user object (say AD) to another user class (say database) factory method, and have the database user class check if it has ever existed before for this user and if so, instead of recreating itself, just grab the cached copy. I'd rather not use a central cache to do all of this caching, but instead store the cached information in the actual objects (just seems cleaner that way).
What I can't figure out though is how to accomplish this (from a design perspective). So I'm looking for recommendation on which design patterns might help me to figure out an approach to creating this functionality.
P.S. Just in case it matters, all user classes extend different base classes, however, they all implement a shared interface.
Sounds like the appropriate caching at the various services that are responsible for looking up the related User instances would be the most appropriate approach. Using the Cache plugin would make this quite trivial.
Your factory method could delegate to the appropriate service method which would be annotated with the correct cache. Just keep in mind that you will need to invalidate items in the cache as well if they are subject to changes.
Having a bit of an issues on design, and was hoping I could ask for advice here. Accept that grails may be the completely wrong tool, but such is life.
So have been working away on a web app that basically just present a lot of information from a google spreadsheet and sends some updates back. I have managed to get most of it working but decided to rewrite it to get rid of my ridiculous spaggeti code as well as the many pieces of broken code that lays strewn throughout the project.
The system is relatively small, two-three users. The amount of data is small as well. One worksheets with max 500 rows (four columns) and another one with potentially 5000 (four columns). So all small, but I need it (well, want it) to stay in the google spreadsheet and the application feeding from there.
There are three classes I need for this to work,
Google authentication class keeps information on keys and tokens to speak to google
Google Spreadsheet class keeps information on the source spreadsheet
Google Data Entry keeps information from the two spreadsheets based on a unique id
So here is my question, what should I define these classes as. Thought I would use Domain classes, but then realised that these are stored in a database. Is there a way of keeping domain classes session dependent, I.E., that two users can use the same app on the same server but never see each others data and that the data is destroyed on logout. If not, is there some other class I can use that works similar to Domain class but kept in memory user/session specific.
I'm not really sure what exactly your requirements for those classes, but here are some thoughts anyway.
First, you may want to ask if they can't just be "normal" classes in src/groovy. I say "normal" here in the sense that they may just encapsulate some data and behavior, and you are responsible to create instances of them and call the methods appropriately when needed.
But, if you want to tie some data and behavior to the user session (as you seem to, because you asked for session dependent domain classes), you may want to use a Grails Service with session scope. When you do that, Grails will use a different instance of the service for each session of your application, and reuse the same instance for the same session until it ends.
You may also use a bit of each thing, using one service with session scope and have other classes representing the data that you pass around from the controllers to the service and vice-versa. These could actually be Command Objects if you needed validation and data binding, for example.
So I want to build an application with MVC 4 and Entity Framework 5. I've build simple applications before, but now I need some security around my current effort... I have some confusion / questions that I was hoping someone could answer;
First... Using the MVC 4 Internet Application Template it implements SimpleMembershipProvider. I have read every primary article about modification, implementation... However, this uses a Code-First implementation...
Problem: I have an existing database that I would like to import the scheme for to an EDMX database first approach... How do I implement the MVC 4 Simple membership provider when my database ties tightly and directly into the user table (userid)?... I know I can use my own user table as long as i designate the userid and username fields as documented... Will this affect the provider, or the existing "AccountController" code? Will these need to be modified?
Second, what I am looking for is a workflow with this architecture... I am "old school" mostly database first approach... My project is a huge WIP (work in progress). I have a foundation, but will need to expand as needed... Can someone provide some insight into database first vs other approaches when there will be quite a bit of change management occurring?
you can still use Code First to map to an existing database. You may need to explicitly map properties to table columns because the mappings do not follow the default conventions, but that doesn't prevent you from using Code First.
When transitioning from DB first to another mindset. Focus on how the objects interact with each other. then, at some point you will save the state of the objects after they interacted. This is where the ORM comes into play. detects changes and executes the necessary SQL statements to persist the current state of the objects.
Think of the database as just another storage container. In theory it could be replaced by another persistent storage mechanism (document db, file, persistent hash table, in memory list, etc.). In reality it's not that simple, but the idea of treating the DB as just a simple storage container helps to break away from the monolithic database concept that is/was ingrained into most devs.
But don't loose perspective of the design either. If it's a simple forms-over-data app where you will be adding features in the future than keep the design simple. than don't try to totally abstract the DB away. you know it's there and the relationship to the UI is almost 1:1, so take advantage of that.
In it's simplest form separation of concerns can be achieved by using the MVC controller to manage the interaction between the model (mapped to the DB via ORM) and the view (razor templates) my personal preference is to keep ORM out of the views so I typically query the database, map the domain model to a viewmodel and then pass the viewmodel to the view.
Again if it's a simple application and screens map directly to the database than viewmodel are probably overkill.
Question
Should autoincremented identity columns have a non-default seed/increment when used in a RESTful web application?
Background
I'm working on my first ASP.NET MVC application and trying to keep my urls RESTful. There is no separate administrative web site for the application. I use attributes to control who can access what parts of the site and what menu items are visible to the current user based on their roles in the system. I (mostly) follow the ActiveRecord DB pattern and use synthetic ids for my tables, including the user table, with the ids being autogenerated identity columns.
It occurred to me this morning that there is a subtle security risk to using default seeds for identity columns in a RESTful application. If you assume that administrative ids, particularly the most powerful ones, are typically created first in an application, then it follows that they will be the lowest numbered ids in the system. While not actually opening a hole in the application, using default values for the seed/increment could make it easier for a cracker to attack a high value target simply by targeting low numbered ids using RESTful actions (such as ChangePassword -- which is one of the out-of-the-box actions in the ASP.NET MVC site template).
Should I add setting a non-default seed to, at least, my users table to my arsenal of security best practices? Is the effect of doing this worth it? Or am I being too paranoid? As a related question, should I be changing the out-of-the-box template names for account-related actions.
My advice is to use GUIDs instead of autoincrementing IDs. That gets rid of the "guessing game" altogether.
I have been very skepticle of using Guid's; however, as Lucerno points out it does help minimize the guessing game depending on how the Guid is generated and used. Guids generated using sequential from SQL Server, would not prevent the guessing game for example.
Guids are also very handy if your have a domain model and your using an ORM like nHibernate or even rolling your own. As it simplifies greatly the complexity of inserting the backreferences since all objects can be given their id's early on.
With that said if your Id's are included in the URL they should be treated as very public data. Even over HTTPS a devious attack could get the whole URL. If your page requests any third party content such as Google analytics for example, the url query string and all, is sent to the third party as the referer for example.
Keep the logged in user on the session on the server side rather than passing it to the client - that way the client can never alter the user id in a malicious query.
I've decided, for now, that I'll address the risk by changing the default seed for autoincrement columns. This isn't hard and won't change the character of the application or the ActiveRecord pattern. Since these columns are also used for foreign key relationships I want to keep them integers to make the indexes more efficient.
I'm not planning on change the default actions unless a different verb makes more sense. Having the interface be intuitive is more important than hiding the action behind an obscure name.