This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Most application servers come with a way to manage security. Authentication is by username and password. The container will return a username and can check to see if the user is in a role. The following examples will use the user.xml file:

    <user name='Janne' password='dog' role='admin,superuser' />
    <user name='Foster' password='turtle' role='admin,editor' />
    <user name='Susan' password='cat' role='editor' />
    <user name='David' password='penguin' role='editor' />

and part of the web.xml file:

           <web-resource-name>Protected Area</web-resource-name>

           <web-resource-name>Protected Area</web-resource-name>


In this setup, a user must be Authenticated to use Edit.jsp and Delete.jsp. They do not need to be Authenticated to use any other url such as Wiki.jsp or Diff.jsp. Once a user is Authenticated, only users in the editor role (Foster, Susan, David) can use Edit.jsp to edit pages. To use Delete.jsp you must have the admin role (Janne and Foster). Users that try to access these pages without the proper Authorization will get back a 403 Forbidden error page.

The above setup gives unlimited view access, somewhat limited edit access and very restrictive use of delete. For most sites, this setup works as a decent control method.

Page level security#

Restricting access to a page is not possible using the basic Container Managed Security. The problem is that the JSPWiki url looks like:
The page is in the query string (the part after the question mark). The standard container is not able to use the query string as part of the security-constraint. If the URL was in the form of:
then container managed security would work[1].

The other issue with doing page level security this way is that each and every page needs to be entered into the web.xml. Which means that an administrator needs to be involved and that means payment in pints of beer or shouting a round of whiskey.

In the 2.1.x JSP Wiki there is a way to page level security that is managed by the users.

For users of the 2.0.x JSPWiki you can attempt to use the Auth Plugin to have page level security.

Both allow the user to put directives in the page to control who views and edits a page.

2.0.x: [{Auth allow='admin' deny='Janne' edit='editor' }]

2.1.x: [{ALLOW view admin}] [{DENY view Janne}] [{ALLOW edit editor}]

Both of these say Allow anyone from the Admin group look at this page, except for user Janne, and anyone from the group editor can change this page

Here are more details on the 2.1 Authorizatization setup.

See Auth Plugin for details on how that page level security can be setup using it.

[#1]But the URL does not look like that, and it's not going to look like that, so get over it.

"Container Managed Security" doesn't mean you have to use declarative security for everything. Although, it means that you use standard J2EE APIs for doing programmatic security when not doing declarative security. Just because you can't declare security for Wiki pages doesn't mean you have to abandon J2EE security altogether. You could programmatically enforce wiki page authorization using Container Managed authentication (users/roles).

JSPWiki 2.2 (2.1 Alpha) Container Manager Security#

I thought I had found a solution to my problems of getting container manager security to work with 2.2 page authorization. It works once a person is logged in. The problem is getting them logged in since Wiki.jsp isn't secured (in a typical setup, edit.jsp would be secured but not Wiki.jsp). So there's nothing to trigger the login for a view. So I tried using the form based authentication instead of basic and converting the JSPWiki login forms into standard login forms like this:

<form method="POST" action="j_security_check">
<input type="text" name="j_username">
<input type="password" name="j_password">

However Tomcat doesn't allow direct linking to the login and throws.

message: Invalid direct reference to form login page

description: The request sent by the client was syntactically incorrect (Invalid direct reference to form login page).
That is, it wants a request to a secured resource to trigger the login and redirect you to the login page, not just let someone login by going to a page with a login form.
  • So how do you avoid this error allow people to choose to login in Tomcat without going to a secured page?

or for a solution that works with both BASIC and FORM login...

  • So does anyone know how you'd programmatically throw a login required to the container?
I know that might mean changes to some existing auth* stuff, but I'd really like to know how to do that.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This particular version was published on 23-Mar-2004 23:34 by