Overwrite a plugin GSP and Controller within another Plugin
Asked Answered
S

2

4

I have a fairly complicated grails plugin dependency structure within my project and I am having problems overriding classes from the security plugin.

My structure is a little something like this:

Web App
 |_ Audit Plugin
     |_ Spring Security Core Plugin
 |_ Security Wrapper Plugin
     |_ Audit Plugin
     |_ Spring Security Core Plugin

The reason it is like this is audit is shared between some apps which have the security wrapper, and some what don't, which is why it pulls in Security-Core (it needs at least the ability to get the current principal).

Similarly the wrapper is shared between multiple web apps therefore we put it in a plugin. My problem comes after upgrading Spring-Security-Core to version 2.

My wrapper has a customer auth.gsp and LoginController.groovy. In the older version of security this was fine, as the plugin templated those and made them available in the source of the installing plugin.

However now these files are internal to the plugin, and although I know you can override them within the main app, when trying to override them within another plugin I get some bizarre results.

The Spring-Security-Core version of the login page always overrides my custom login page. I cannot get mine to take precedence.

The second problem is that the LoginController.groovy from the Spring-Security-Core plugin sometimes takes precedence over my one from the wrapper. It seems almost random between builds as to which one will be in use.

Is there any correct way to go about making sure my views and controllers take precedence?

Scurrile answered 18/7, 2014 at 13:8 Comment(2)
I have the same issue. It looks like adding List loadBefore = ['springSecurityCore'] to plugin definition workarounds this, but I'm not sure if this is valid approach...Schroder
My problem is that I've had such problem with modifying the load order of these plugins as the wrapper sets up some of the config for spring-security-core and also overrides some of the beans. Changing the load order breaks that. I've just about got that bit working by loading after the security core plugin, changing it to load before would break it.Scurrile
S
5

OK playing around with things I found a solution that seems to work for me:

Firstly I couldn't change the order in which the plugins load because the security wrapper does a lot with spring beans and it has to load after the core plugin for this to work. So after a bit of digging in the (DefaultSecurityConfig.groovy) I noticed that you can set the following properties:

grails.plugin.springsecurity.failureHandler.defaultFailureUrl = '/login/authfail?   login_error=1'
grails.plugin.springsecurity.failureHandler.ajaxAuthFailUrl = '/login/authfail?ajax=true'
grails.plugin.springsecurity.auth.loginFormUrl = '/login/auth'

So I created a custom controller and login page which have a different name to the ones use in the core plugin and changed these properties to point to my locations.

To neaten this up, in the UrlMappings for the wrapper (named: SecWrapperUrlMappings) I put a mapping from /login/** to /seclogin/**.

Make sure that these new locations aren't locked down so that people can access them and that seems to work well. I now reliable know, whichever order they load in my login page and login controller are used.

Scurrile answered 21/7, 2014 at 11:26 Comment(2)
Too bad I can only give one up vote. Saved me from going home without a fix after a day of trying several different hacks to get our application to use our own LoginController on all the development machines.Ridley
Did not worked for me.Algesia
A
0

In Grails-4.013 and spring-security-core-4.0.4, I did the following trick.

In my custom plugin instead of LoginController and LogoutController I named them as SigninController and SignoutController respectively. And in UrlMappings.groovy of App mapped them like..

static mappings = {
    "/login/$action?"(controller: "signin")
    "/logout/$action?"(controller: "signout")
    ....
    ....
}
Algesia answered 8/1, 2022 at 6:42 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.