I am trying to use an ini file to login into a grails application with the shiro plugin. I have created an ini file and put it in the config folder. The ini is displayed below.
[main]
[users]
admin=heslo, Administrator
[roles]
Administrator = *
[urls]
I created a service with the method createSecurityManager() which I call at bootstrap:
def createSecurityManager() {
Factory<SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
SecurityManager securityManager = factory.getInstance();
println securityManager
SecurityUtils.setSecurityManager(securityManager);
securityManager
}
When I try logging in using the username admin and password heslo, the login fails.
have you tried the quick-start described in the plugin documentaion?
http://grails.org/plugin/shiro
In order to use an ini-file, I guess you have to create your own realm.
When using the grails shiro plugin, I think the easiest way to use it is to create the standard DB-Realm and initialize it in the bootstrap - the same way the quick-start describes it :-)
But the Shiro CAS configuration should be done using the ini file approach right?
I've been referring to this link: http://shiro.apache.org/cas.html
Is there a way to configure CAS authentication with the quick-start approach that comes without an ini config?
Related
I know there is a Flyway2 plugin. However im not satisfied since it seems fitted for working by console commands. What i want is to integrate Flyway in a programatic way so:
1st Integration tests use flyway to handle db schema with H2 database
2nd Flyway get's triggered on tomcat deployment and handles also the environment database (maybe through running it from bootstrap?)
Does anyone has experienced with this?
EDIT after some discussion:
In order to use the plugin i would need to get a fully configured instance of GFlyway from spring context. This becomes difficult since the bean only property is def config from where it will read all the required properties. The question is how to replicate this behavior within the resources.groovy ... how to provide the application config as a parameter to the bean.
As we have been discussing in the comments, the correct way to configure this as a bean would be:
// Resources.groovy
beans {
grailsApplication = ref('grailsApplication')
gFlyaway(gflyway2.GFlyway) {
config = grailsApplication.config
}
}
Configure the settings as usual within your Config.groovy per the documentation of the plugin.
That should get you closer, if not all the way there.
As described in Can't call one closure from another, I am using a pluggable script from within a Grails app.
Unfortunately, I've found that I can't use log4j from within these scripts. I am forced to use println.
I tried using
import org.apache.commons.logging.LogFactory
def Log log = LogFactory.getLog(getClass())
but I got no output. When I print out the result of the call to getClass(), I get something like
myscript$_run_closure5
So I'm thinking the issue is that there is no configuration in my Grails Config.groovy file for this class.
Is there a way for me to programmatically add these pluggable scripts to the log4j configuration? Keep in mind that I do not know in advance what the names of the scripts are, so this has to happen at runtime.
Consider the following code:
import org.apache.log4j.Logger
// ...
Logger log = Logger.getLogger('MyPlugin')
new File( grailsApplication.config.externalFiles ).eachFile { file ->
Binding binding = new Binding()
binding.variables.log = log
GroovyShell shell = new GroovyShell(binding)
shell.evaluate(file)
strategies.put( binding.variables.key, binding.variables )
}
Explanation:
It is not obligatory to pass class name to getLogger, it can be actually any string. You just need to make sure that this string is matched in log4j.properties of the main program.
You pass once created log to plugin scripts via binding variable "log". Then plugin scripts can access it simply as log.info('test123')
My personal recommendation would be to use logback instead of log4j. Both libraries were developed by the same guy and it is stated that logback supersedes log4j.
I'm working on a payment plugin for the grails framework. I'm using a payment provider which gives me a SOAP API (WSDL) and I need a cxf-client to communicate with the webservice.
I installed https://github.com/ctoestreich/cxf-client (cxf-client plugin) in my grails plugin project (2.2) and want to use the cxf-client I added to my config.groovy in a grails service.
In the Service Class I just added
RecurringPortType recurringPaymentClient
I don't start the plugin project directly, instead i included it in my mainproject where I use some methods of the plugins service (also autowired into my mainproject).
After using the autowired plugin service (which works) I get a nullpointer exception using a method which uses the autowired cxf-client in the plugins service class. The cxf-client bean reuccringPaymentClient is null.
But why? Do I have to include the cxf-client configuration also into my mainprojects config.groovy? Or is there a solution my mainproject can merge or also use the config.groovy of my new plugin? At this time the cxf-configuration is placed in the plugins config.groovy - Maybe that's the problem?
Using
RecurringPortType recurringPaymentClient = ApplicationHolder.application.mainContext.getBean("recurringPaymentClient")
as described in cxf-client documentation didn't help.
The Config.groovy file in a plugin only applies when the plugin is run as a standalone application itself. It is not read when the plugin is used in another application. A trick I've seen some plugins use (and which I have stolen for one of my own plugins) is to manipulate the configuration in the plugin descriptor's doWithSpring, which is usually early enough to have the required effect. In your case you'd have to make your plugin loadBefore the cxf-client plugin to ensure that your doWithSpring (creating the config) happens before that of cxf-client (which is where the settings will be used).
class MyCleverGrailsPlugin {
def version = "0.1-SNAPSHOT"
def loadBefore = ['cxfClient']
def doWithSpring = {
application.config.cxf.client.recurringPaymentClient.clientInterface = com.example.MyClientPortType
// etc. etc.
}
}
Or you can use ConfigSlurper by hand
def doWithSpring = {
ConfigObject pluginConf = new ConfigSlurper(Environment.current.name).parse(com.example.MyPluginDefaultConfig)
application.config.cxf = pluginConf.cxf.merge(application.config.cxf)
}
This loads a Config.groovy-style script from the plugin's src/groovy/com/example/MyPluginDefaultConfig.groovy, and merges the cxf section of that config into the cxf section of the main application's configuration, with settings in the app overriding the defaults supplied by the plugin.
Section 3.4 of Grails documentation says that Grails app can be configured from an external source:
grails.config.locations = [
"classpath:${appName}-config.properties",
"classpath:${appName}-config.groovy",
"file:${userHome}/.grails/${appName}-config.properties",
"file:${userHome}/.grails/${appName}-config.groovy" ]
Also, it is possible to load config by specifying a class that is a config script:
grails.config.locations = [com.my.app.MyConfig]
My questions are:
Could you please give an example of how MyConfig class implementation could look like? It is not quite clear from the documentation.
If I want to use some external JSON REST service as a source for my config data, how can this be implemented?
Answer for second question: you can do that in BootStrap.groovy init closure, because basically, it allows you to execute any code:
// Inject grails app
def grailsApplication
def init = { servletContext ->
def externalValue = getItUsingRest(someUrl)
grailsApplication.config.my.custom.var = externalValue
}
Depending on version of grails you are using, you might need to use
org.codehaus.groovy.grails.commons.ConfigurationHolde.config
to get to config instead.
Your application configuration can actually be a Groovy script. So any class which looks like your Config.groovy can act as a configuration class. In our projects we tend to keep the configuration outside the grails application so that the application can be configured without recompiling everything.
Maybe this post of mine will give you a hint on how to use and load external configuration files.
I am trying to do salted password hashing in my Grails + Spring Security application. I have used the tutorials on the Grails site, and also ones I found randomly on the Internet.
At the moment, I have everything set up according to this tutorial. However I run into a problem when deploying the application with the following bean declaration in resources.groovy:
saltSource(cq.MySaltSource) {
userPropertyToUse = CH.config.grails.plugins.springsecurity.dao.reflectionSaltSourceProperty
}
It complains that it cannot find CH.
After digging around, I found a post on nabble stating the following:
Also - don't use ConfigurationHolder (CH) since it's deprecated in 2.0. You can pass in a reference to the grailsApplication bean and get the config from there:
saltSource(MySaltSource) {
grailsApplication = ref('grailsApplication')
}
and then in your class add
def grailsApplication
and get the property via
String userPropertyToUse grailsApplication.config.grails.plugins.springsecurity.dao.reflectionSaltSourceProperty
The part that I do not follow is the last statement about "...and get the property via...". The line of code he gives there seems malformed to me.
If anyone can shed some light here, or provide a different approach to using salted passwords with Grails and Spring Security, I would appreciate it. Note that it needs to be unique salts per user, not system-wide or a single salt, or a salt derived from username.
Thanks
UPDATE
So I got it working with the first tutorial (forgot the import statement at the top of resources.groovy. But I would still like to use the second way (to stay compatible with the future version).
UPDATE 2
I have written a complete tutorial on this if anyone browsing here is interested:
Setting up a Grails web application using Spring Security and salted passwords.
In resources.groovy where you're defining the saltSource bean the GrailsApplication is available as the application variable, so you can change the bean declaration to
saltSource(cq.MySaltSource) {
userPropertyToUse = application.config.grails.plugins.springsecurity.dao.reflectionSaltSourceProperty
}