The project layout is pretty straightforward for the basic stuff, but I'm looking to write some code for my security layer, generating and authenticating tokens and the like, and I'm not sure where that belongs.
For example, I want to create a class that extends WebSecurityConfigurerAdapter to authorize requests. Where does this belong? The init folder? Services?
Since you're not coding Grails artefacts (ex. controllers, domain classes) then src/main/groovy is a good place for them.
Related
I'd like to make my usage of open-dolphin in grails sever as easy as possible. So, I'm looking for way to handle CRUD actions on domain classes(on the server side) automaticaly. In demos from open-dolphin project I havent found any idea how to achieve this(if I missed something, please point me where I should study). Instances are pulled from server on request and until it would be pulled/updated again there is no way to recognize changes that happen on server(I've been investigating mainly crudDemo in open-dolphin project).
Since CRUD actions can come not only from user via web or remote client, but also as consequence of other actions, cascade deletes, from services etc.(changes made to the database via sql, are probably untreatable), I thing that handle actions in classes controllers is not enough.
I came up with idea of handling CRUD actions using GORM events, with those I can keep dolphin models persistent with database, check PMs before update or delete, and probably handle all changes on domain classes instances that grails is doing. But, I have to write very similar logic to each class, be sure I havent missed any event on any class(scaffolding may help) and there are probably other consequences that I do not realize now..
So my question is: Is there any documentation, pattern, plugin, open-source code, etc., where open-dolphin is implemented into grails that way, that it autamaticaly propagates CRUD actions on domain classes instances to its presentation models? Or anything that aims to achieve this, using scaffolding, observing instances lists and properties, or something else?
Maybe, I misunderstood concept of using open-dolphin with grails, if so, I appreciate any good advice.
Thanks a lot!
for some reason I haven't seen your question before.
You can happily use Grails domain classes and GORM with OpenDolphin on the server side. The "CrudDemo" in OpenDolphin does exactly that.
Here are the domain classes: https://github.com/canoo/open-dolphin/tree/master/dolphin-grails/grails-app/domain/dolphin/grails
Here are the actions: https://github.com/canoo/open-dolphin/tree/master/subprojects/demo-javafx/server/src/main/groovy/org/opendolphin/demo/crud
Note that when we do testing and client and server-side actions run in-memory, there is no grails support available. Therefore, the server-side actions use service interfaces with DTOs instead of Grails domain classes. The implementation as a Grails service then uses Grails domain classes and GORM.
enjoy
Dierk
I'm working on a project in Grails 2.0.RC1 and I'd like to be able to save the scaffolded controllers and views for my domain objects to have as a "low-level", developer only access to still tinker with things while being able to develop the production version of the views and controllers (with similar names, especially for controllers). I'd like to preserve them as-is, so I can re-generate them as I make updates to the domain layer, so just moving them is most likely not going to work.
I'm hoping there's a way to do some UrlMapping magic that would let me have requests for "/mgr/book" go to the scaffolded Book controller, but "/book" would go to my production controller. I can't find anything in the docs about how to have mappings for specific groups of controllers (without specifying each controller by name versus a $controller notation).
My other thought is to turn my domain layer into a plug-in and then create a separate project that would be just for the scaffolded views. This would be easier to remove before going to production, but also seems like more work, and raises the issue of running two grails apps at the same time on the same box.
I would advance you to go like your last idea. This is also my common approach:
Create an embeddable plugin for your domain model and common services. This also includes common plugins, like spring security and stuff. This will also reduce your dependency resolution time for the main-app btw.
Create an embeddable plugin for your scaffolded views. Change the template of the scaffolded controllers to require authentication and admin-group.
Your main-app uses both plugins.
This keeps your main-app clean and simple and you can still regenerate all your scaffolded views & controllers as you wish. And at least Eclipse STS hot-deployment will still work!
However there is no simple solution for seperating your scaffolded controllers URL-wise yet.
If you are using Spring Security, you should be able to use an InterceptUrlMap or RequestMap Instances to secure the controller URLs.
If your scaffold controllers are only used for scaffolding (and don't have other actions), then you should be able to use basic Secured annotations to secure the entire controller.
Then you can use the scaffolding like normal, protected behind a login.
Other security frameworks may provide similar access control.
I would like to restrict access only for ROLE_ADMIN users to all controllers introduced by the Spring Security UI plugin in grails. (I am using grails 1.3.7, plugins.spring-security-core=1.1.3 and plugins.spring-security-ui=0.1.2)
I can run the config script and create a blank controller for each of the various controllers the ui plugin defines, and decorate that blank controller with #Secured(['ROLE_ADMIN']), but that seems like a tedious and unnecessary approach. Is there a better way?
Thanks,
Gene
Since you're using annotations, the easiest way is to use the controllerAnnotations.staticRules config option. This is for static resources and controllers like these where you shouldn't edit them (or jump through hoops to secure them).
See section "5.1 Defining Secured Annotations" in http://grails-plugins.github.com/grails-spring-security-core/docs/manual/
Been lurking for a few months and decided to jump in with a question. I am very new to Windsor and IoC in general. I can get Windsor to work with my MVC2 project with no problem. The project I am working on is a "portal" of multiple applications under one MVC2 project using the new Areas concept. In this scenario, each Area will actually be a separate application inside the "portal". We are doing this to effectively share a LOT of common code, views, authentication, and cross-application functionality. Many of our apps link to one another, so it made sense after discussing it to combine them into one project.
What I am wondering how to do is actually allow different Areas to inject different concrete classes? In my limited understanding, the Application_Start is governing building the container and assigning it as the controller factory. I don't necessarily want to do all the injection at the application level. We have a config system where we have a config.xml at the root of every Area and those settings override any root settings. I would like to continue that trend by having the injections for each Area be read by the Area's config.xml (an inheritance similar to Webforms web.config where the config in a lower folder overrides settings in a parent folder).
Example: I would have an ILogHandler which would need a different concrete implementation depending on which Area of the application I am in. So I would need to inject something different depending on where I am at in the application.
I can easily do this using factories since each area could have it's own set of factories, but I am attempting to take this opportunity to learn about IoC and what the benefits/drawbacks are. Any help would be appreciated.
Just FYI - you absolutely must not have area-specific security code. For example, a factory or invoker which injects [Authorize] attributes depending on the current area could open your application to attack.
Contrast this with a MyAreaBaseController, which all controllers in your area must subclass. [Authorize] attributes (and other security-related code) here are OK since they're applied to the type and are independent of any concept of "area".
Documentation says:
The Grails team discourages the
embedding of core application logic
inside controllers, as it does not
promote re-use and a clean separation
of concerns.
I have one API controller and a few Groovy classes in src/groovy folder. Those classes just implements my application logic so actions in API controller works in this way:
//index page
def index = {
render new IndexApi().index(params) as JSON
}
I'm curious - is there any reason to move my application logic from plain groovy classes into services ?
Actually services are not just about transactions. Services are great for zero-config injectable singleton components, and they can can be reloaded without restarting the whole grails environment, AND they can be discovered as artefacts and hence automatically exposed with remoting plugins.
If you want transactional behavior you should put your logic in the Services. Else you would have to take care about it yourself, which is not in the spirit of using Grails.
Being not a grails expert myself, I put my 'not transactional' classes outside the service layer, like builder classes, helpers, and other logic that is not transactional but used from the service layer.
There are three reasons:
It makes the controller smaller -> easier to understand and maintain
It makes you logic easier to test.
You really don't want to manage your transactions manually.
If you would put everything in the controller, you would need to create the Web runtime to be able to run any test. If your logic is outside, you can copy the data you need from the HTTP request and all the other sources and just call the code. So the logic isn't depending on HTTP sessions, requests or anything else you don't want to.
For example, to test JSPs, you need a HTTPRequest. For a request, you need a HTTPSession and a JSPWriter. Those need a session context. So just to be able to run a single test, you need to set up and initialize a whole bunch of classes. And all of those are interfaces and the implementations are private. So you must implement the actual methods (all 300 of them) yourself. And you better get this right or your tests won't test what you want.