Since the introduction of the excellent info.magnolia.cms.security.auth.callback.CompositeCallback and info.magnolia.cms.security.auth.callback.RedirectClientCallback classes there is no more need for this module!

magnolia-module-urisecurityfilterextension offers flexible login behavior depending on the protected uri that was called. The behavior is fully configurable via the Magnolia configuration.

For those not interested in the technical setup, skip to the paragraph "Putting it all to gether" at the bottom of this page. Be sure to read the instructions however. Do not test the module on a production environment.

Magnolia features a pretty sophisticated access control mechanism which will redirect you to the Magnolia login page when you request a url you are not authorized to. This behavior is configured here:
config: /server/filters/uriSecurity

Magnolia comes with two "out-of-the-box" login methods:

• Standard magnolia login window
  This login method is used, when info.magnolia.cms.security.auth.callback.FormClientCallback is set as class under /server/filters/uriSecurity/clientCallback. It is a Freemarker based template "hidden" somewhere (/mgnl-resources/loginForm/login.html) in the Magnolia resources - you don't want to modify that.
• Basic http authentication
  This method is used when you set info.magnolia.cms.security.auth.callback.BasicClientCallback as the clientCallback class. A simple browser login mask will be displayed - you cannot modify that.

There are a few more clientCallback classes (see the info.magnolia.cms.security.auth.callback package). I did not have a closer look at these classes though.

When creating a custom website, you usually don't want to display a standard CMS login page when a user wants to access a restricted area. Neither do you want to use the basic http authentication form because it is not multilingual, you cannot display custom error messages etc.

Most likely you would want something really flexible, like

• when somebody tries to log into the cms, the standard Magnolia login mask (i.e. Freemarker) should be displayed,
• when somebody calls the secured path /to/my/secret/page a jsp-based cms page with a login form should be displayed,
• when an other user wants to access /other/site/restricted/area again a jsp-based login page should be displayed, but a different one - in the look&feel of /other/site
• when somebody calls anything like /site1/... a basic HTTP authentication form should pop up,
• and in any other cases again the standard Magnolia login page should be used?

A client callback system this flexible would need

• a custom configuration with url patterns and corresponding client callback handlers
• a smart client callback class which is capable of dealing with all these situations

So the client callback class must be able to compare the requested url with a list of patterns and then forward the request to one or the other client callback classes.

To display an arbitrary cms page instead of the standard Magnolia login page we need to do the following:

• Write a custom clientCallback class with the corresponding behavior 
• Create a JSP template with a login form
• Instatiate a cms page with that template
• GRANT ACCESS TO THIS PAGE FOR THE ANONYMOUS ROLE!!
• Change the class value of the clientCallback node to WebsiteFormClientCallback
• Change the loginForm value of the clientCallback node to the path to your login page
• Restart Magnolia AFTER YOU'VE CHECKED THAT YOU CAN GET THE LOGIN PAGE WITHOUT BEING LOGGED IN.

 If you don't grant access to the login page for the anonymous role you will lock yourself out. To make sure this will not happen open two browsers (e.g. Firefox and Safari), stay logged in with one browser and test the access functionality with the second one.

IF YOU LOCK YOURSELF OUT, IT'S YOUR OWN FAULT!

So now, we can login using a standard magnolia page. Of course we could add all kinds of logic to that login page. But wouldn't it be much nicer if we could reuse the already existing client callback methods depending on which uri was called? Let's create a PatternClientCallback class which can be configured with many different client callback methods depending on uri patterns. To get this working, let's have a look at how these client callback classes are instantiated first.

On startup of magnolia all filters are automatically instantiated - including the stuff under /server/filters/uriSecurity which is where the client callback object is defined. In order for these configuration nodes being turned into objects, they need to have a "class" nodedata. Then, the objects have to be in "Bean"-style, which means they need getter and setter methods for each additional nodedata (e.g. getLoginForm() and setLoginForm()). Of course, nodedata can only correspond to a simple java value. If your bean object should contain further complex objects, these have to follow the same guidelines. For lists of objects - in our case "patterns" you need to create a array of this type and the following two methods:
- getPatterns()
- addPattern()
The configuration for our extended client callback object could now look something like this:

When you have a good look at the configuration, you will notice 3 custom classes:

• PatternClientCallback
  This class handles the client callback calls and compares the uri that was called with the list of patterns, forwarding the call to the first matching pattern.
• ClientCallbackPattern
  This simple class consists of a pattern string (with "*" and "?" wildcards) and a callback object which will do the actual work if the pattern is matching
• WebsiteFormClientCallback
  This finally is the class that is able to display a cms page as login form.

If you think this could be useful for you, feel free to download the custom module below and give it a try. However there is one important thing to know about this module:

NOTE: USE AT YOUR OWN RISK!

That's all there is to know.

Click on the two links below. You should be facing two different login windows:

1. Link 1: The sample login page, a (rather ugly) standard cms page
2. Link 2: The basic http authetication pop-up of your webbrowser

Again, AT YOUR OWN RISK, you can do the following:

• Drop the magnolia-module-urisecurityfilterextension-1.0-SNAPSHOT.jar from the target folder into the WEB-INF/lib folder of your magnolia test instance (don't try this on a production system first!)
• Restart Magnolia and let it install the module.
• Copy the clientCallback node from config: /modules/urisecurityfilterextension/sampleConfig to /server/filters/uriSecurity, renaming the existing clientCallback node there to something like clientCallback_backup
• Configure the patterns inside the new clientCalback node to your needs.
• The installation process has added a sampleLoginForm template (under config: /modules/templating/templates) and "login" page in the root of the website tree. Feel free to move this stuff to where you like, but be sure to configure the path to the page in the clientCallback configurations of the type WebsiteFormClientCallback (node "loginForm") accordingly.
• Grant access to the login page to the role "anonymous". TEST THIS USING A SECOND BROWSER, i.e. not a second browser window, but a second, independent web browser. Use a second computer if you cannot run two independant browsers on your system. You will need to modify the "website" ACL as well as the "URL" ACL.
• If you can access the login page without having been logged in already and without the Magnolia standard login form beign displayed, you most likely setup the ACLs correctly.
• Finally, stay logged in as superuser on one browser, log out on the second one and restart Magnolia. Now call a URL you have defined a pattern before. Instead of the standard Magnolia login form the method you have defined in the pattern should be triggered now.

As mentioned before, use this module at your own risk and responsability. Therefore there is no such thing as warranty of any kind or free support - of course we would be happy to support you on a consulting basis.

However here's a hint in case you should happen to have locked yourself out due to misconfiguration: You can gain access to the admin interface again by adding the login info to the url, e.g.

http://localhost:8080/magnoliaAuthor/.magnolia/pages/adminCentral.html?
    mgnlUserId=superuser&mgnlUserPSWD=superuser