I have two different Java Applications A and B. They should use the same Database for user management (If the User has an account in Application A, he also has an account in Application B and vice versa).
Both Application A and B have exactly the same User class. But when I create an User in Application A I can't retrieve this same User in Application B and vice-versa.
I've read in a forum:
db4o is able to do this. Different application can use the same
database and access data of others "if you provide refferences" to the
projects. I mean if you put your entity in a class library and add it
as references to projects it wont be a problem
How could I achieve this?
Thanks in advance for any help.
db4o stores the fully qualified name of classes so if you want to access the same database from two (or more) different apps (with different package structures for the model classes) you have basically 2 options:
Have your model classes as a separate project used by the applications;
Configure aliases
Hope this helps.
Adriano
Related
I'm still pretty new to the grails framework and working on legacy application based on grails 2.
I have a domain controller allowing authenticated users to do all basic CRUD actions (create, read, update and delete), with "Read" including list and show.
I need to create another controller/view now allowing any user (non authenticated ones too) to be able to read only (list and show).
I looked around but could not find any "tuto" to do so ...then here's my question:
What would be the best approach to complete this task?
I looked into 2 options:
Option 1
Modifying the current domain controller (class level) #secured annotation in order to annotate only create, update and delete methods. I tried to do so, but it seems like I still have to authenticate which I suspect is related to SpringSecurity "grails.plugin.springsecurity.controllerAnnotations.staticRules" config that I may need to modify too.
Option 2
Create a new controller from scratch (but I guess I can't ask Grails to generate a second domain controller for the same class) then it means quite some work to build up all the data I need.
I'm not even sure if any of the 2 options above is recommended... has anyone faced this problematic (I'm sure many have) and if so ... what was the recommended approach?
Thanks.
I have a project that use the USER_ROLE to give access to different people to different parts of the project. But people still need to login.
I also have another project in C#. There is 2 copies of the same project. The public project is a copy of the main project. However, the public project is accessing the VIEWs set up from the database. It is not accessing the actual tables. So, the public project can have only read only access to a subset of the database records. It is only reading the VIEWs.
I am new to Grails. I don't know if you can set up the domain to access a view or not.
I am thinking outside the box. For your project, is it possible for you to create a new "public-read-only" project. Copy and paste the parts from the main project to the new "public-read-only" project that you want to give people to access.
In this case, your new project is a subset of the main project but it is accessing the records from the actual database tables.
What do you think?
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.
I recently finished an application using just standard grails way (GORM-domain classes, etc.), but the company is asking me to to include an existing DB from an open source project. Both are just using mySQL DB, which is good, but I'm not sure how to approach this. I've seen some posts regarding grails connecting to multiple DB.
I guess my question is: Is it possible to connect to two databases: one mapped to domain classes and the other not? My primary reason to do this is to keep all the code in one project and reuse code without gutting the project and making a plugin.
Thanks for any insight.
Yes. It is possible - http://grails.org/doc/latest/guide/single.html#multipleDatasources
Whether you map the other database to your domain classes or use it through a service layer is up to your design.
Thanks for the answer. I was also able to find a tool that helps generate the domain class from an existing DB. The tool is called GRAG (Grails Application Generator) which although is not perfect, it is a bit of a help getting me started faster.
I hope this helps others as well.
I’m working on a Grail’s project that has some Domain objects not persisted on the database. They are managed thru a REST API, so all their CRUD operations will be done with this API instead of the database.
The point is to still be able to use some interesting Grails plug-ins (like searching using Compass).
For instance, the administration the Domain objects Users is going to be managed with the REST API, so when the Users list is displayed a the REST method to retrieve the list of users will be invoked on the remote server. I hope this use case is clear enough :)
I can think on several ways to design that but I'm not sure what’s the best:
Should I create the Domain Objects in the controller (and delete the
previous Users stored in memory)?
It seems it’s possible to define a Domain Class not persistable (with
mapping I think) but I’m not sure if this is the best approach or
where to load the data.
It is better not to model as a Grails the User as Domain object?
Thanks in advance!
I would wrap the REST interactions in a service, and call the service from a controller. In that case, the service would get the response and create its objects, passing the list back to the controller. Controllers should just handle incoming requests, invoke application components, and return responses.
It seems you want models to represent the data in the other application, which is a good idea. Since you don't need GORM, you might want to define them in the 'groovy' folder of your app instead of the domain models folder. Then I think they will just be objects.
I'd go with non-domain objects in src folder - though, need to check if it's possible to use the mentioned plugins with them.
I wonder what domain class functionality you wish to get out of non-persistent classes?
I'm developing a multi tenant app architecture that is quite complex.
.
3 completly different kind of app
Ther is no only one type of application used by many customers; ther are 3 different kind of applications.
APP A, APP B, APP C
.
Each APP is multitenant
Each app has its customers.
APP A
- customer A1
- customer A2
APP B
- customer B1
- customer B2
APP C
- customer C1
- customer C2
.
SHARED INFORMATIONS
Many informations are shared betwen the different apps
"customer A1" need to manipulate or only view data owned by "customer C1"
.
QUESTION
Consider that i'm using Asp net mvc, EF, Sql Server.
Wich is the correct implementation?
One site and many Areas?
Create multiple sites?
Multiple db? Only one db? Filtering? Sql filtered view? ...
Some application example?
EDIT
and... Where to put the business logic?
I would recommend that you first build your own multi-tenant engineering stack (Framework) on top of .Net which will handle all the requirements of multi-tenancy in terms of tenant wise data isolation, support for horizontal scaling, filtering of views based on the tenant context and role of the user, tenant wise data model extension, tenant wise UI customization, enforcing access restrictions based on roles, privileges and data scope - which could be different for different tenants etc.
The business logic can be built on top of this framework. This approach will provide your product a robust and strong engineering foundation.
The other alternative is to buy a ready to use multi-tenant engineering stack off the shelf, install it on Visual Studio and use it as a development template.
Ideally in a multi-tenant server with a single app you want physically different databases for each tenant, rather than just a column specifying which tenant the data belongs too
But either way you have to ensure that ALL database functions use the correct database connection or tenant column key. That is the real issue
The way to make sure of this is to have only ONE function per app that makes this decision, and make sure all database functions fail if they have not called this function (directly, or indirectly as below)
e.g. With MVC in the global.asax AuthenticateRequest or BeginRequest function you can validate who the user is and then calculate which database connection they need to use or what tenant column key they must use in EVERY query for that request. This is then stored in a session variable etc
If you have three apps, I would make three separate sites. They can share common classes via a shared project. Life is generally easier if they can be deployed separately
This is a concrete answer, but just some some aspects you may consider when designing this.
With regards to shared information, I think the most important part here is to define the relationship between customers and the roles and rights each customer has with respect to other customers. The best approach is to start with is identifying what exactly can be done.
Example:
Read Only|cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 1 | 0 | 1
Write |cust1|cust2|cust3
---------+-----+-----+-----
customer1| 1 | 1 | 0
customer2| 0 | 1 | 0
customer3| 0 | 0 | 1
So in the above, customer1 can read and write(update) customer2's data.
This being said, the main issue is model these relationships i.e. the shared information. Using #TFD's suggestion, these relationships can be loaded into session for when a customer logs on along with the relevant tenant id's.
(Based on the information provide, my other inclination is that this may be a per application concern and not a customer only concern. To illustrate this, replace the 'cust' values in the above tables with App.)
Create separate sites for each application since I am assuming that each application has a unique purpose although there is shared functionality.
Maybe a different Config DB is needed if there are other cross data relationships. The DB would store all the tenant information (incl. relationships to other Apps) for each App. The reason for this suggestion is that from what I can see, you have three separate multi-tenant apps independent of each other using a shared DB approach - but each App need to interact with another App on some level.
In terms of customers within the DB, I would then suggest that the 'Customers' table be confined to the Config DB. You can then have a content DB based on each applications requirements.
My suggestion is to use PRISM with Sliverlight and MVVM design patten. PRISM is designed for such kind of composite application where each application is independent and can also communicate with each other via Events exposed by PRISM.
You can have multiple approaches - since the app is data driven, it makes sense to build a database design that secures the data even in case of application bugs.
One way to do this is ensure that there are stored procs for accessing any tables and the security logic is built into the stored procedures. You can ensure that a different db username is used for each customer, and that this db user name is mapped against that tenant id in a mapping table. Then the stored procs can always have a check that the data being requested/modified is actually belonging to the tenant id mapped to the db user who is running the proc (by using context information).
Then you will need some way to ensure that the db connection created by the application uses only the corresponding username that maps to that tenant id. This means you need one more stored proc that gives you this information (with probably username/id as the input) and this stored proc should be executable through a common db username. Remember, this is the only stored proc that needs to have execution priveleges given to this common db user.
This might look like writing a bunch of extra code, but it really helps to know that your db will reject bad requests even due to application bugs. The only place you have be really, really careful is the place where you get the right tenant db username and password for that user id, and that should be quite possible.