JSecurity Plugin

This is actually a tricky problem: the view is in the plugin, but the layout is in the application. So, somehow the plugin context path must be cleared once rendering reaches the layout - easier said than done I think.

In the meantime, I would simply copy login.gsp from the plugin to your grails-app/views/auth directory. This also enables you to customise the look of it.

Since it is fairly easy to work around this problem, I'm dropping it down to minor.

Various changes to the plugin have made this issue redundant, I believe. Re-open if it's still a problem for you.

Hi,

I had this same problem, I just installed the plugin jsecurity, now on version 0.2 at grails 1.0.2 and the problem appeared again. I made a controller with an create action to add users to my website and when the page was load, the page try to look for the js libraries inside the jsecurity folders, as describe bellow:

<script type="text/javascript" src="/multilinguas//plugins/jsecurity-0.2/js/jquery-1.2.3.cust.js"></script>
<script type="text/javascript" src="/multilinguas//plugins/jsecurity-0.2/js/application.js"></script>

and at my create.gsp I defined on this way:

<g:javascript library="jquery-1.2.3.cust" />
<g:javascript library="application" />

Unfortunately, to avoid this I defined base_href equals to the name of my aplication and I had to call directly the js using the tag <script></script>. The other pages that the controller does not use the Jsecurity, loads normally, without any problems to find the js library.

So I think that a part of this bug remains!

Thanks

Rogério Carraqueira

I've also just come across this issue with a fres 1.0.3 app and the lastest jsecuroity pluhin - installed the plugin, ran grails quick-start (which created grails-app/views/auth/login.gsp) and my webtests are failing (after clicking sign in on the login page) due to invalid JS library links on the pages using the main layout.

cheers

Lee

I'm sorry, I am confused by this issue. I too encountered a similar error when using Canoo Webtest and Jsecurity. What is the "fairly easy" workaround to which Peter Ledbrook alludes?

In my grails-app/views/layout/main.gsp file, I replaced the line

<g:javascript library="application"/>

with

<script type="text/javascript" src="/codegrader/js/application.js"></script>

since the latter is how the former is dynamically rendered at run time (unless the bug under discussion incorrectly renders it as mentioned in the previous comments). However, I don't entirely understand the former line (it was placed in main.gsp by default by Grails), and I am afraid that some future change in Grails (for instance, moving the location application.js) will break this.

So what is the correct workaround for this bug?

Thank you in advance,
Dave

I am also seeing this problem with the JSecurity plugin. Once a user authenticates, all <g:javascript.../> tags on every application page render with a bogus path, such as:

<script type="text/javascript" src="/plugins/jsecurity-0.2.1/js/prototype/prototype.js"></script>

As soon as the user signs out, all paths are rendered correctly. Unless I am doing something wrong, this is a critical bug.

I am using Grails 1.0.3 and JSecurity Plugin 0.2.1 with the login page in the application view directory.

<g:javascript library="application"/> is incorrect in my opinion. It should be:

<g:javascript src="application.js"/>

The workaround I mentioned is to copy the login.gsp file from the plugin to the application view folders. So, I suspect that this report is not for the bug that you are seeing. In fact, I suspect it's a bug in Grails instead. Please try the "src" version of the <g:javascript/> tag - if that still doesn't work, I think it may be a Grails bug.

Here is the problem. In the Grails "JavascriptTagLib.groovy" file, the src path is appended with the value of "pluginContextPath" if it exists:

def requestPluginContext = request[CONTROLLER]?.pluginContextPath
		out << '<script type="text/javascript" src="'
		if (!attrs.base) {
            def baseUri = grailsAttributes.getApplicationUri(request)
            out << baseUri
            out << (baseUri.endsWith('/') ? '' : '/')
			if (requestPluginContext) {
			  out << (requestPluginContext.startsWith("/") ? requestPluginContext.substring(1) : requestPluginContext)
			  out << "/"
			} 
			out << 'js/'
		} else {
			out << attrs.base
		}
		out << attrs.src
 		out.println '"></script>'

I've verified that after authentication, the value of "request[CONTROLLER]?.pluginContextPath" within a tag lib is "/plugins/jsecurity-0.2.1".

I don't know if this is a JSecurity Plugin or Grails bug, but it is not the expected behavior that every invocation of the javascript tag have that path appended, right?

Aha. This issue only affects applications which have controllers that are listed in the JSecurity plugin.xml file under resources. For some reason, that file contains an entry for BookController, ItemController, TestController, AdminController, and a bunch of other stuff (and lots of repetitions - is it automatically generated?)

The logic in DefaultPluginMetaManager matches any resource declared in the plugin and modifies the "pluginContextPath" if the plugin has an entry. So, for people using the sample application (BookController) or others using controller names listed (in my case, TestController) the JSecurity plugin path gets added to resource paths.

Fix is to remove the extraneous entries from the JSecurity plugin resources list.

Patch to be applied to an existing JSecurity plugin installation to remove controllers from the plugin.xml resources.

The resources in plugin.xml come from the test projects in the plugin directory. I have to manually move the "test/projects" directory out of the plugin before packaging it. Hopefully the "PackagePlugin" script will not include them in plugin.xml in future.