Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.

Tech:Acegi integration

ktip.png This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: IMPLEMENTED. Acegi (now Spring Security) was integrated into JAMWiki for the JAMWiki 0.5.0 release.


Acegi Security System for Spring allows to accommodate JAMWiki to different authentication and authorization schemes.

Possible scenarios include:

  • Form based login, users and roles are managed by JAMWiki (default)
  • LDAP based Authentication
  • CAS (Single Sign-On) based Authentication
  • Portal integration



Acegi Security has been merged to the trunk and will be included in JAMWiki 0.5.0.


All authentication features of JAMWiki (Login, Logout, RememberMe) now use Acegi Security. The default configuration uses the JAMWiki database, so from a users point of view (almost) nothing changed.

Access Rules examples

Anonymous users are assigned ROLE_ANONYMOUS. Now it's possible to allow exceptions to general access rules, e.g. to protect all pages but login and registration form. The default configuration allows unrestricted access. Additional rules can easily specified by adding URL to role mappings to the definition of filterInvocationInterceptor. For example:


requires login to edit a page, while


protects all pages.

CAS configuration

I've added a CAS configuration example.

  • The main configuration file is applicationContext-acegi-security-cas.xml. It can be enabled by changing contextConfigLocation in web.xml.
  • CAS parameters are retrieved from from the classpath. If CAS is to be fully supported these parameters could be entered in the JAMWIki admin form and stored in insead.
  • CAS can authenticate a user but does not provide user details or authorities. I've provided an InMemoryDaoWithDefaultRoles which assigns ROLE_USER to all users by default. In addition a user to role mapping can be specified, for example to grant ROLE_ADMIN to certain users. This mapping is specified in applicationContext-acegi-security-cas.xml but could also live in a property file making it easily configurable from the JAMWiki administration form.
  • InMemoryDaoWithDefaultRoles can also be used with LDAP authentication when LDAP is only used for authentication but not for role or group management.
  • All users have ROLE_NO_ACCOUNT. This setting hides the user menu "Account" entry which is not useful in a CAS environment.


  • Provide configuration examples
    • LDAP
  • Automatically create an account for an authenticated user. This is useful if authentication is delegated to e. g. CAS but account management shall retain in JAMWiki. Not needed. JAMWiki does not have store any user data, see #CAS configuration.
  • Documentation: how to configure different authentication schemes
  • Attempt to access Special:Admin, or to edit a restricted page, etc. should (if possible) continue to display the supplied WikiMessage to the user to explain why a login screen is being displayed.
    • Once this is resolved the CAS configuration should be updated to display an error message if a user tries to access a resource without proper access rights.
    • I've implemented a fix, but it doesn't really utilize the Acegi framework. If there is a better way to handle this issue it should probably be used.
      • Ryan, I'm not sure about the state of this issue. Have you had a look at exceptionTranslationFilter in applicationContext-acegi-security.xml? If JAMWiki throws different exceptions for "access denied" or "logged in, but not enough rights" or whatever it should be possible to display different messages and/or login screens. -- Rainer 27-Dec-2006 07:24 PST
        • Let's revisit this issue for JAMWiki 0.5.1 - at the moment the code that has been implemented works, although it's not the most elegant solution. Your suggestion definitely sounds preferable, but I'd like to limit any new changes until this release is done. -- Ryan 27-Dec-2006 08:22 PST
  • There are use cases where some links from the user menu should be hidden. In a Single Sign-On environment as described above the user account menu should be hidden, because JAMWiki does not control the user data. Another example would be JAMWiki being embedded in a portal where user account, login, and logout links shold be hidden. Maybe this can be made configurable through properties?
I've got a better solution: we can use Acegi Security Authorization Tag Libraries to hide links if a user owns certain roles. In the default configuration all links are visible, but if a user owns, say, ROLE_NO_ACCOUNT the user account link is hidden. Similar ROLE_EMBEDDED would hide user account, login, and logout links. This way the authentication configuration would control the visibility of menu entries, and there is no need for further configuration properties or admin forms. What do you think? -- Rainer 05-Dec-2006 09:20 PST
I'm still getting up-to-speed on Acegi, so I'll continue to defer to your judgment. Taglibs are a clean way to handle this, so it sounds like a reasonable option. -- Ryan 05-Dec-2006 22:44 PST
Implemented in svn using roles as described above. -- 11-Dec-2006 02:54 PST

Help needed

Once I've been able to merge my code to SVN (see below) I'll need some support.

  • Acegi Security can redirect to an error page if access to a page is denied. I've configured it to point to the login form. But there are cases it would be better to deliver an "access denied" message. For example, if you are logged in as a normal user and try to access an admin only page just pointing to the login page is confusing, since you are logged in. This can be configured in applicationContext-acegi-security.xml (exceptionTranslationFilter). I'm just not sure how to display the "access denied" page.
  • The Virtual Wiki login problem (see below) could be solved similiar: provide a page "Login successful" within each virtual wiki and configure acegi to require a ROLE_USER to access it. The login link just points to this page. After logging in acegi will forward to the page, the user is still in the virutal wiki.
  • Remove obsolete code (e.g. LoginServlet, Utilities.login() etc).
  • Clean up WikiUser. I've marked some methods deprecated, because WikiUser implements an Acegi Interface which caused some properties to be duplicated.
  • Ryan, I think there is a bug in svn: DatabaseUserHandler.authenticate(login, password) used to call WikiBase.getQueryHandler.lookupWikiUser(login, encryptedPassword). Now it calls WikiBase.getDataHandler().lookupWikiUser(login, encryptedPassword), where encryptedPassword is interpreted as transactionObject. This causes authenticate to accept any password.
The authenticate() bug has been fixed - very embarassing, so thanks for pointing it out. As to the redirect issues, I can take a look once the code has been merged. It sounds like the best solution is (like you said) an intermediate page that Acegi can redirect to that will contain logic figure out what the next step should be. -- Ryan 01-Dec-2006 12:05 PST
I've removed the obsolete code you noted above. I noticed your suggestion about a protected "login successful" page after implementing a different solution (see #Updates), and I'm not sure which is better - your suggestion is less of a hack than mine, but the implementation I've done should allow a successful login to redirect to the original page that the user was trying to access (not tested yet), rather than just showing them a "login successful" message. I'm still looking into how to provide more useful messages when access is denied, but I suspect that the new JAMWiki subclasses of the login filter may allow some flexibility in passing message strings. I need to get to bed, but please let me know if you have any thoughts. -- Ryan 03-Dec-2006 01:37 PST
"but the implementation I've done should allow a successful login to redirect to the original page that the user was trying to access": this should work anyway. If a protected page is accessed by an anonymous user acegi will redirect to this page after successful login. Only the "Login" link needs special treatment with virtual wikis, e. g. a "Login successful" page for each virtual wiki. Anyway, your filter approach does solve more problems than this one. -- Rainer 04-Dec-2006 05:44 PST

Feedback required

Ryan and others, I need some feedback:

The default behavior is implemented. The only change recognizable from a user's perspective is that the user is not automatically logged in after registration or setup. The reason for this is that it's impossible (or just difficult?) to log in a user programmaticaly because we don't know which authentication method and backend is configured with Acegi Security. In my opinion this is not a problem. It's common behavior to present a login form after registration; in addition it opens up the possibility to validate a user's registration data by email before login is allowed. Is that alright with you?

I tried to change as little of the original code base as possible. Now it's time to remove superfluous code and polish the integration code. But that's only useful if you're going to integrate the code into the main branch. How do we proceed?

-- Rainer 29-Nov-2006 08:51 PST

I'll take a look at your code today and let you know any comments. Provided it's not too intrusive and can be easily integrated we should be able to integrate it for 0.5.0. I think Axel has some experience with Acegi as well, so it would also be good to get his (and anyone else's) comments prior to integrating. -- Ryan 29-Nov-2006 10:27 PST
I'm going through the code now, and here are a few thoughts. Keep in mind that I'm not at all familiar with Acegi, but your code seems easy to follow (nice job!):
  • Is the oro.jar file needed? I couldn't find any imports in your code that used it, so I assume it's a dependency of one of the new JAR files. If it is needed, can you add a license file for it?
Done. Jakarta ORO is a regular expression library used by Acegi Security.
Thanks! One further request - when it is merged can you add the version number to the file name, ie oro-2.0.8.jar? It makes it easier to make sure that all JAMWiki JAR files are up-to-date.
  • Can you upgrade the spring-dao.jar and spring-support.jar files to 2.0.1 prior to merging? I've just upgraded the rest of the Spring files for JAMWiki.
  • I don't think that the Acegi source files in lib-src are needed - is there a reason to store them in the respository?
The source jar is useful within Eclipse for JavaDoc help and debugging. I added it for 2 reasons: (1) it is referenced in .classpath (see below). (2) I'm working at the office and at home, so I use the repository to sync my workspaces.
For now I'd prefer to leave this out (you can still include it in your local development environment), and we can discuss merging this sort of code as part of a larger discussion about supporting Eclipse and other IDEs. Hopefully that's OK.
  • Similarly, I'd rather not merge any of the Eclipse environment files now. If there's interest in getting that code into the repository it should probably be done separately - I don't use Eclipse, but others who do use it might have some feedback.
Eclipse users checking out the code from repository have a working Eclipse project setup without any additional work. On the other hand those tiny files don't bother any other IDE as far as I know. But of course they don't have to go into the main branch if you don't like so.
On a side note: I've set up the project so all .class files and resources are build to WEB-INF/classes. This was I can instruct Tomcat to use the source tree as webapp dir and all changes are visible without an additional deploy step. Changes to JSP and non-structural changes to Java are even visible without a Tomcat restart or webapp reload.
See the comments below - I'm not opposed to merging Eclipse support to trunk, but I'd rather have a separate discussion about it. For now I think it would be better to simply merge Acegi code.
  • I assume the log4j information is not needed? If it is, how is it used? JAMWiki has been using java.util.logging for some time now due to some difficulties in log setup encountered by some users with log4j.
Done - removed log4j setup.
I couldn't get Acegi logging to work with the JAMWiki setup. It works if I use the -Djava.util.logging.config.file parameter and add these lines to
 handlers = java.util.logging.ConsoleHandler
I think it's a configuration issue - I need to make sure that the JAMWiki log configuration is read prior to performing any other configuration. It's been a to-do item on the Known Issues list for a while now, but I'll look into getting it resolved.
Logging is a mess if an application server and different webapps are involved :-( Do you know Spring Log4jWebConfigurer? It's not perfect in all environments, but helps to specify which logging configuration is loaded by a webapp (and even can reload it at runtime). It requires an expanded .war, though. -- Rainer 01-Dec-2006 00:59 PST
I actually spent some time looking at logging options today. I think that the current logging can be made to work with Acegi by using LogManager.getLoggerNames to get current loggers and configure them to work with JAMWiki logging - I was going to revisit this issue once the code was merged to trunk. If that doesn't work then the Spring log4j classes are an option, although when previous versions of JAMWiki used log4j one user reported permission problems (see Comments:JAMWiki 0.3.4), and as I recall log4j did not offer any way to verify that loggers were successfully created. -- Ryan 01-Dec-2006 01:17 PST
  • Can a shorter name than "applicationContext-acegi-security-formLogin.xml" be used? Perhaps just "acegi-security.xml"? I'm not sure if there's a naming standard here that I'm unaware of, but that's a huge file name ;)
Spring often is configured to load all files starting with "applicationContext-". Next to being able to load all context definition files with one expression it's a nice thing to recognize all Spring related files by name, so I would recommend to follow this convention. The remaining part of the name can of course be truncated. I will provide more configuration examples which probably will go into different files to avoid confusion, so I will have to invent meaningful but short names. :-)
As long as there's an existing file naming standard being used then I guess it's fine to keep the naming as-is. It's just a shame that Spring chose to force such ugly file names on us!
  • Is there any overhead in the new Utilities.currentUser() method? For example, will this query the database every time the method is called, or is the retrieval mechanism lightweight? This isn't a huge issue, but the old mechanism (retrieving from session) was very lightweight, and if that has changed some optimization might be needed in the rest of the code.
Once retrieved from the database on first login the UserDetails object is cached, so this should not impact performance.
  • The UpgradeServlet login process is a mess - I need to fix that prior to 0.5.0, so you don't need to worry about it.
  • Once Acegi is merged and known to be working any unused code (LoginServlet methods, etc) can be removed.
  • When using LDAP the jam_wiki_user_info table is unused, and the encoded_password field won't be set. Since you've added a lookupWikiUserPassword() method, will that affect your changes? Note that the remember_key field in jam_user should also contain the encoded password and might be a better value to retrieve (I was using it as the "remember me" cookie value field).
LDAP will use a different AuthenticationProvider, so this change is unrelated. If I recall correctly the password is only used to create the rememberMe cookie. I will have a look at the remember_key field.
  • If login fails (due to incorrect login/password) is that state of the "Remember Me" checkbox maintained?
Neither the checkbox nor the login/password fields are maintained if login fails. Actually I don't know how this could be achieved, since I don't have access to the controller setting the model values... Is that a problem?
This isn't a big deal - it would be nice to have, but it's something that we can look into as a future enhancement.
I don't think any of these are major issues, so unless anyone has objections I think you can begin merging to trunk. This may delay the final JAMWiki 0.5.0 release a bit, but from what you and Axel have said it sounds like a very worthwhile project. Let me know if you have any questions or need anything else from me. -- Ryan 29-Nov-2006 16:30 PST
Regarding the Eclipse issues: I'm not opposed to merging support for Eclipse, but I'd prefer to do it as a separate discussion. I don't personally use Eclipse, so if any code is merged I'd like to make sure there are at least a few people who can maintain it. Also, if there is any way to avoid having lots of different IDE-specific files I think that would be preferable, although I'm not sure how to merge Eclipse support without opening the door to other IDEs, so feedback is appreciated.
If you need any help merging your code to the trunk please let me know - I'm heading to bed shortly but should have some free time tomorrow. Thanks again for all of your work! -- Ryan 30-Nov-2006 00:54 PST

Virtual Wikis

I have a problem with the login to a virtual wiki other then the default "en". Login and registration work fine, but redirect to /en/StartingPoints, and not to a page in the virtual wiki. The reason for this is that the login URL to watch is specified in applicatonContext-acegi-security.xml, as is the page to forward to afterwards. If the login is not triggered by a "login" link but when entering a protected page (e.g. if edit operations or all pages are protected) everything is fine, because Acegi will forward to the original requested page after successful login. Any ideas? -- Rainer 30-Nov-2006 07:58 PST

An ugly solution would be to have Acegi pass the virtual wiki to a page that figures out where to redirect to. I don't think this is an important enough issue that it should hold up getting your code merged into the trunk, but it should be resolved before the final 0.5.0 release. -- Ryan 30-Nov-2006 11:54 PST


If I understand Tech:LDAP_integration correctly a user sucessfully authenticated against LDAP is logged in with user privileges. I. e. only user validation is handled by LDAP but not role management. Specifically there is no way to assign an admin role via LDAP.

Acegi Securities default LDAP support handles both: a user is authenticated in LDAP performing a bind operation or password comparison. On success groups in LDAP are used to derive the user's roles.

In addition one could implement an LdapAuthoritiesPopulator rebuilding the behavior of Tech:LDAP_integration: if a user is successfully authenticated a default role is assigned, so no groups have to be maintained in LDAP. This is a nice solution if only "normal" user roles are needed. Even some special accounts could be handled by providing some role mappings in applicationContext-acegi-security.xml. But if a more complex scheme is needed, LDAP groups are the way to go.

I guess what I'm trying to say is

  • Tech:LDAP_integration could be completely handled by Acegi Security
  • In addition Acegi Security can handle roles via LDAP groups
  • From a JAMWiki configuration view CAS integration is quite similiar to LDAP integration

What do you think? -- Rainer 30-Nov-2006 09:03 PST

Agreed with all three bullets - one of the things I like about Acegi is that it means we shouldn't need any custom security code. My understanding of Acegi is that it offers a lot of flexibility for handling users and roles, so once it is merged into the trunk we can begin looking at ways to better use its capabilities and to get rid of some of the current JAMWiki code.
Unless you see a reason to wait I'd like to get your code (minus the Eclipse changes, for now) merged onto the trunk. If you'd like I can do the merge work, or you're welcome to do so. Having seen your code I'm confident that you can continue working directly on the trunk (if you're comfortable doing so), which should hopefully make future integration and feature enhancement easier. Let me know if that sounds OK to you, and with any luck the JAMWiki security and authentication features should advance fairly rapidly over the next few days. -- Ryan 30-Nov-2006 11:54 PST
I'll merge today after fixing some minor issues. Next week my time will be limited because I have to prepare and deliver two presentations and a full day workshop, so the merge should be done soon. -- Rainer 01-Dec-2006 00:31 PST
Sounds good - let me know if I can help out. Once merging is done I can also look into any bug fixing, including some of the issues you've outlined above - just let me know where I can help. Starting on Monday I'll have less time for JAMWiki work, but will hopefully be able to get some work done in the evenings. -- Ryan 01-Dec-2006 00:35 PST
I merged everything locally but was not able to commit the changes to the main branch. It seems I'm not allowed to add new files ("403 Forbidden (". Is this a sourceforge problem or did you protect the main branch? I'll try again tomorrow morning... -- Rainer 01-Dec-2006 06:57 PST
According to it appears that Sourceforge was doing Subversion work, and repository URLs may need to be changed soon. As far as I'm aware there should be no restrictions on project members for working with the repository. Let me know if the problems continue, although it appears that Sourceforge has finished most of their work.
I changed the repository URL and after some strange errors I was able to commit. -- Rainer 02-Dec-2006 03:25 PST
I tried to setup a configuration for Ldap with Acegi, please take a look at Tech:Acegi_Ldap. Of course there are still some limitations but perhaps it could be the right direction. Thanks for comments! --hp 18-Mar-2008 04:57 PDT

Further Acegi integration

There are several items on the to-do list, including implementing user roles, using Acegi for LDAP integration, etc. One thing that (in my opinion) is holding up further Acegi integration is the need to use XML files for configuring security - as much as possible I'd like to use the Special:Admin tool or some other web interface to centralize configuration and prevent users from having to know anything about the internals of Acegi or any other technology. Since Acegi is an extension to Spring it is possible to use other configuration methods (see here for one such discussion) but I'd also like to avoid writing a lot of custom code.

As a result, my current thinking is that:

  1. We should utilize Acegi functionality for LDAP, user roles, etc.
  2. HOWEVER, there should be a web interface to control this configuration.
  3. We don't want to write a lot of custom code, extend Acegi (or Spring) in ways that might break, or have to pull in a lot of experimental libraries.

My familiarity with Acegi and Spring is still growing, so if there's an easy way to accomplish the three goals above (or if anyone has suggestions) it would be helpful to hear any ideas. I'll continue investigating, so with any luck a potential solution will hopefully emerge in the next week or two. -- Ryan 07-Jan-2007 23:32 PST

I agree with your goals. I recommend to deliver pre-configured configuration templates (XML application contexts) for different authentication schemes (as we do for database and CAS already). Deployment specific settings can be read from plain property files using Spring's PropertyPlaceHolderConfigurer. Those property files can easily be configured using the JAMWiki administration console.
To avoid editing web.xml the selection of the configuration file to use can be handled in an application context definition, too: web.xml references a single Spring configuration file, say applicationContext.xml (which is Spring default). In applicationContext.xml the configuration to use is included by an import statement, again configured using PropertyPlaceHolderConfigurer. Thus, all standard deployment specific settings are handled in property files managed by the JAMWiki administration tool, while the tuning of expert settings or even the integration of new authentication schemes is still possible by editing or adding Spring configuration files. -- Rainer 09-Jan-2007 00:48 PST



Have you considered to use Acegi Security System for Spring for all authentication and authorization related topics? It would help to provide different authentication setups like LDAP, CAS and the integration of JAMWiki in portals. Rainer 21-Nov-2006 04:28 PST

+1 for ACEGI Support from me :-) --Axel Kramer
Where were you guys a week ago when I was starting work on LDAP integration? :) I'll take a closer look at Acegi - they appear to have a lot of nice features. The Thanksgiving holiday is coming up so there may be limited JAMWiki development over the next few days, but I'll definitely try to get a sense of how much work would be required and whether support for something like Acegi is best integrated directly into JAMWiki or as an extension by next week - if anyone has more information to share, please do! -- Ryan 21-Nov-2006 12:07 PST
In that week my harddisk crashed (lame excuse :) ) So I don't know if this is helpful, but here is a short outline of the steps which were necessary to integrate ACEGI into Roller weblogger: [1] -- Axel Kramer
Ryan, I'll try to integrate JAMWiki with our CAS environment. Since I have some experience with Acegi Security and CAS I might be able to contribute some code. What code base do your recommend to start with? 0.5.0 beta2? Rainer 22-Nov-2006 00:46 PST
If you're working on new features I'd definitely recommend the latest 0.5.0 since there have been many changes since 0.4.3. If you're comfortable working with Subversion let me know what your Sourceforge ID is and I can get you access to the Subversion repository, in which case you could do work on your own branch - see How to Help#Programmers for details. I'm unfortunately going to be out of town for most of the next 4-5 days, but I can answer any questions or what have you when I return. Thanks for the offer to help! -- Ryan 22-Nov-2006 11:18 PST
My Souceforge ID is rainers. I'll have to try wether sf subversion access works in my corportate network, though. Rainer 23-Nov-2006 07:54 PST
I've added you to the project - the standard message for everyone is to please be careful when making any commits to trunk that they are either discussed first or else obvious fixes, but you're welcome to do anything you like with a private branch. My online time will be limited during the next few days, but please post any questions you might have and I'll try to get online at least once a day to check. Cheers! -- Ryan 23-Nov-2006 08:26 PST
I've just managed to create a private branch from behind a corporate firewall... all is needed is a working https connection, svn works fine through https. The only thing you might want to be aware of is that while creating the branch I found that my old svn client is not working with sourceforge's svn repository. However, after installing the latest svn (from source in my case), it worked fine. Simply checking out works with older clients too, but the branch creation did not... Cheers, Csaba 23-Nov-2006 08:28 PST


I made a few additions to the Acegi code - please revert if I've screwed anything up. I wasn't able to logout from a non-default virtual wiki, so I updated the logout link to hard-code "/en". If there is some way to set the logout URL to /**/Special:Logout in the Acegi configuration that would be better, but from my reading of the docs and the code I didn't see one.

I've also added Special:Translation and Special:Convert to the admin-only list. And I've deleted a number of the methods that were marked deprecated, as well as the LoginServlet.logout() method which I believe is now handled by Acegi. -- Ryan 02-Dec-2006 23:19 PST

Is LoginServlet needed anymore? -- Rainer 04-Dec-2006 04:30 PST
To be honest I wasn't sure - there are a few places in the code that redirect to it, such as from EditServlet when a user tries to edit a page that is admin-only and the user isn't an admin. If Acegi handles that sort of thing then feel free to remove it, otherwise I'll investigate. I start a new today so my time is going to be significantly limited for a bit, but I'll try to take a look at this tonight when I get home. -- Ryan 04-Dec-2006 08:06 PST
As a test I got rid of LoginServlet, but then logging in from a virtual wiki (such as /test/Special:Login) failed. Ideally we could just sub-class AuthenticationProcessingFilterEntryPoint to handle virtual wikis, but that class is a bit tough to sub-class. I'm sure there are other solutions - suggestions are welcome, otherwise I'll take another look at this tomorrow. -- Ryan 04-Dec-2006 22:26 PST
I've made two more updates by extending the Acegi login and logout filter classes to handle virtual wikis. This isn't the best of solutions since it could potentially break with future Acegi updates (Acegi appears to not be designed for this kind of approach), but it works in the interim and I'd be curious to hear your feedback. There are still two more hard-coded references to the "en" virtual wiki in the applicationContext-acegi-security.xml file that may need to be dealt with, but it's very late here and I need to sleep. -- Ryan 03-Dec-2006 01:30 PST
Looks good to me. In fact I think it's the approach recommended by acegi security. Another option would have been to redirect to a special controller handling the virtual wiki URL logic. This way you wouldn't have to implement special filters. But it would add another redirect, so I think your approach is better and opens up more options to handle messages and other special cases. -- Rainer 04-Dec-2006 04:28 PST

The user is now logged in automatically after registration. -- Rainer 04-Dec-2006 07:18 PST

Great! -- Ryan 04-Dec-2006 08:06 PST


Hi Rainer - I'm still getting up to speed on Acegi, but when compiling on my local machine today the user menu in the top right part of the screen disappeared. I believe that this is because login no longer grants ROLE_USER by default, but I could be wrong. In any case, assuming that a logged-in user won't have ROLE_ANONYMOUS I simply changed the tag to check for !ROLE_ANONYMOUS, and the user menu is now appearing again. If there's a better way to handle that situation please feel free to upload a change. -- Ryan 12-Dec-2006 21:43 PST

You are right. Since login is not handled by Acegi in the current svn configuration, no roles are assigned if a user is logged in. Your approach works, it just seems a little bit unusual to me to check for an absent role for logged users. -- Rainer 13-Dec-2006 05:08 PST
It's because of method AnsiDataHandler.initWikiUser(WikiResultSet rs) create users without any GrantedAuthority at all. I see it's need to use WikiUser constructor in such a way (see line #714)--Gloomy 05-Feb-2007 07:36 PST:
			final GrantedAuthority[] ga = new GrantedAuthority[] {new GrantedAuthorityImpl("ROLE_USER")};
			WikiUser user = new WikiUser(
Thanks for the tip - I'll look into it the next time I have time to sit down and write code (please remind me if I forget!). -- Ryan 05-Feb-2007 23:34 PST
Is there allready a solution for this or is this issue solved and I ran into configuration-problems? I have configured a LdapAuthenticationProvider to work with Active Directory. Login works and the authenticated user gets his roles, of course role ROLE_USER is missing... After login, there is no link for edit, logout is missing too. 10-Mar-2008 08:26
This functionality isn't well-supported as its not something that a lot of people are using. If I understand your issue correctly, you've configured LDAP to provide the correct roles, but they aren't being reflected in your JAMWiki installation? If that's the case I can take a look and see if there's anything that's been obviously broken in the code. -- Ryan 10-Mar-2008 08:19 PDT
You're right, the LDAP-Configuration was successful, but the User-Entry is still missing in some parts... I've added an bug report. --hp 11-Mar-2008 04:29 PDT