I'm in the process of converting a rather large Grails 2 application to Grails 4. It uses the Shiro plugin, which I have upgraded to version 4.3 (compile "org.grails.plugins:grails-shiro:4.3"). In one large GSP (which has always worked OK), the Shiro taglib is now causing the following error:
Error executing tag <shiro:isLoggedIn>: No SecurityManager accessible to the calling code, either bound to the org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an invalid application configuration.
The SecurityManager is initialized OK in Bootstrap.groovy, and in another simple test page, shiro:isLoggedIn works fine. So my question is why might the SecurityManager not be available in this use of the taglib? What should I be looking out for?
I'm not a Grails person, but one common reason folks see this problem is that the ShiroFilter did not process the request (or the filter is not configured early enough in the chain).
What happens is the ShiroFilter creates a Subject (the user) and associates it and the SecurityManager with the request thread. Other API (like the tag lib) would use that Subject and/or SecurityManager.
Check your servlet filters, maybe compare them with the old version with the new version and see what has changed.
G'day John, I look after the grails shiro plugin. That error occurs in the taglib because for some reason I'm trying to track down, the ThreadContext doesn't appear to be available. That means the SecurityUtils goes looking for a static security Manager which isn't normally set in web applications.
So basically it's a bug, and hopefully I'll fix it shortly (help welcome).
Related
Grails 2 had a plugin for that, there also used to be
request.getFile
method. There is no method like this in Grails 3 as far as I can see, or a plugin.
I tried using
request.getInputStream
But this one is always empty. Other thing I tried was by using Spring-boot way of handling Uploads, but this one relies on
#RequestParam("file") MultipartFile file
It cannot be used in Grails, controllers there do not allow parameters to be defined this way AFAIK.
How to upload files in Grails 3?
Actually there is
request.getFile(fileName)
in Grails 3 as well. It was just not displayed in autofill in my IDE for some reason (the rest of the request methods like getParameters or isPost are displayed correctly).
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?
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.
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")
....
....
}
My small Web API project (hosted via SelfHostHttpServer) has a few dependencies I want to inject into the controllers. In order to do this, I have implemented IDependencyResolver and called httpConfig.ServiceResolver.SetResolver.
This would work fine, except it seems I need to satisfy the internal dependencies the Web API requires. The first time I ran it, I saw that it needed to resolve the controller factory, so I added an instance of DefaultHttpControllerFactory to my container. Now every damn time I refresh the page, it crashes with the next unresolved dependency the framework is trying to resolve.
Am I going about this the wrong way, or am I really supposed to try and guess all of the default implementations and be forced through this crash-fix-refresh cycle of discovering what dependencies are required for the Web API framework to work correctly?
What your resolver is doing in case it can't resolve the dependency? The proper behaviour should be returning null. ASP.NET Web API DependencyResolver (httpConfig.ServiceResolver) is internally using two resolvers:
The one you set through SetResolver (user rosolver)
The built in DefaultServiceResolver
If user resolver returns null for dependency then Web API falls back to DefaultServiceResolver which can handle all built-in dependencies.
Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.
I have a plugin with domain, controller and view pages. (Using grails 1.3.6)
I run the plugin as standalone, the views work fine. URL: http://localhost:8080/sample-plugin/gp/list. I am able to view the list page.
I installed the plugin into a main application i.e. plugin-test. Start as run-app within STS and browse to http://localhost:8080/plugin-test/gp/list. I am able to view the list page.
I bundle the application as war i.e. plugin-test.war and deploy to tomcat. When I browse to http://localhost:8181/plugin-test/gp/list I get a 404 error! I am not sure what I am doing wrong.
I have been trying to resolve it for quite sometime now and still no luck. The same main application works fine in STS but not in tomcat.
HTTP Status 404 - /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
type Status report
message /plugin-test/WEB-INF/grails-app/views/gp/list.jsp
description The requested resource (/plugin-test/WEB-INF/grails-app/views/gp/list.jsp) is not available.
Please help.
Thank you.
Jay Chandran.
This sounds worryingly familiar, as I spent a while figuring out this (or a very similar) issue. I ended up raising this Grails bug report:
Plugin layout not found in war when installed from BuildConfig.groovy
Have you installed the plugin as using the new BuidConfig dependency technique? The JIRA documents my workaround.
Sharing some of my lessons learned after experiencing the same exact issue (1.3.7):
Double check your HTML source to make sure that your template really isn't being included. Mine was being included, but my CSS/image URLs were wrong (only while running as a war)...so I wrongly assumed that my template wasn't there.
Don't use the ui performance tags for referencing your static content...doesn't appear to work, even if the plugin attribute is specified.
Don't name your layout main.gsp. You're guaranteed to have conflicts.
Don't use absolute=true on your g:resource tags. This doesn't appear to append the pluginContextPath to the absolute url, even if you specify dir="${pluginContextPath}"
Don't use pluginContextPath, as it's no longer required: http://grails.org/doc/latest/guide/single.html#6.3%20Tag%20Libraries (search "Plugin Paths")
In your g:resource tags in your plugin layout, make sure you specify the plugin attribute. Set it to the name of your plugin.
Move your static images/css from your plugin to a web server. If each application using your plugin has its own copy, your users aren't going to benefit from caching when bouncing between apps.
Note that all of the above applies to the layout gsp in your plugin project, not your consuming application.