Page Comparison

...

For example if you create a client config with the id of 'main'

Code Block

	xml
	xml
title	Basic client configurationxml

<client:config id="main">
  <title>My Super Client</title>
  <!-- other config content goes here -->
</client:config>

...

You can disable the display of a specific client in this list by setting publish to false in the client config.

Code Block

	xml
	xml
title	Hiding a client configuration	xml

<client:config id="test">
  <publish>false</publish>
  <title>My Test Client</title>
  <!-- other config content goes here -->
</client:config>

...

You can also completely disable a client configuration by setting enable to false.

Code Block

	xml
	xml
title	Disabling a client configurationxml

<client:config id="test">
  <enable>false</enable>
  <title>My Test Client</title>
  <!-- other config content goes here -->
</client:config>

...

This could mean that the user is reduced to a single client config (assuming there is one other client config wither with an ACL that the user passes or it doesn't have an ACL at all) in which case they'll be directed to that config in the same way as they would if there were only one client config.
Or, if they have more than one client config accessible, after the ACL checks, then they'll again be presented with the page listing all available client, but the page will only display those clients that the user has access to (and that are published and enabled).
Finally, if they have no client configs accessible then they'll be directed to a login page.

Code Block

	xml
	xml
title	Client config only available to users that pass the 'admin' aclxml

<client:config id="test">
  <acl>admin</acl>
  <title>My Test Client</title>
  <!-- other config content goes here -->
</client:config>

...

There are two ways to restrict access to Weave so that a user has to be authenticated before they can access the system (well three if you count automatic login mechanisms like NTLM) the first is to use the information above and set an ACL for each client config that disallows access to anonymous users

Code Block

	xml
	xml
title	Restricting access to unauthenticated users	xml

<acl:acl id="authenticated">
  <entry type="deny">anonymous</entry>
  <entry type="allow">*</entry>
</acl:acl>

<client:config id="main">
  <acl>authenticated</acl>
  <title>My Super Client</title>
  <!-- other config content goes here -->
</client:config>

<client:config id="test">
  <acl>authenticated</acl>
  <title>My Test Client</title>
  <!-- other config content goes here -->
</client:config>

The other method is to use security.xml to ensure that the user is authenticated before they can even access the system.
This is done using the FilterSecurityInterceptor in security.xml. By default the FilterSecurityInterceptor supplied with Weave is configured to ensure that each user is at least an anonymous user, this is the lowest level of authentication and basically ensures that we at least have a user object to work with. Changing the objectDefinitionSource in the FilterSecurityInterceptor from IS_AUTHENTICATED_ANONYMOUSLY to IS_AUTHENTICATED_FULLY you cane ensure that the user is forced to authenticate (either via the login page or using non-interactive methods if they're setup) before they can get any further into the system.

Code Block

	xml
	xml
title	Default authentication level in security.xmlxml

<property name="objectDefinitionSource">
  <value>
    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    PATTERN_TYPE_APACHE_ANT
    /**=IS_AUTHENTICATED_ANONYMOUSLY
  </value>
</property>

This section can even be extended to provide different levels of default authentication for different client configurations, for example to ensure the user logs in to access main.html but allow anonymous access to everything else (this doesn't mean an anonymous user can access every other client config, just that that decision will be handled by the ACL's and not by security.xml) you could do the following.

Code Block

	xml
	xml
title	Specific client access in security.xml	xml

<property name="objectDefinitionSource">
  <value>
    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    PATTERN_TYPE_APACHE_ANT
    /main.html=IS_AUTHENTICATED_FULLY
    /**=IS_AUTHENTICATED_ANONYMOUSLY
  </value>
</property>

...

In addition to IS_AUTHENTICATED_FULLY and IS_AUTHENTICATED_ANONYMOUSLY you can also include roles that the user must have before they can access a given client configuration.

Code Block

	xml
	xml
title	Role based access via security.xml	xml

<property name="objectDefinitionSource">
  <value>
    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    PATTERN_TYPE_APACHE_ANT
    /external.html=ROLE_EXTERNAL
    /main.html=IS_AUTHENTICATED_FULLY
    /**=IS_AUTHENTICATED_ANONYMOUSLY
  </value>
</property>

...

Note that the equivalent can be done in using ACL's attached to a client configuration.

Code Block

	xml
	xml
title	Role based access via aclxml

<acl:acl id="external">
  <entry type="allow">ROLE_EXTERNAL</entry>
  <entry type="deny">*</entry>
</acl:acl>

<client:config id="external">
  <acl>external</acl>
  <title>My External Client</title>
  <!-- other config content goes here -->
</client:config>

...

The filter chain proxy determines what steps will be taken when an browser request passes through the security system.
By default Weave is configured with two different filter chains, one for requests from the JavaScript code in the client and one for every other request. This is primarily done for error handling, where we want any errors to be presented to the user using a nice HTML page, but error in response to requests made by the JavaScript code should be in a format that it can interpret.

Code Block

	xml
	xml
title	Default security filters	xml

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      PATTERN_TYPE_APACHE_ANT
      /server/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
      /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
    </value>
  </property>
</bean>

...

This list can be supplemented to perform different actions depending upon what filters a request should be processed by based on the URL of the request, and in this case we're talking about client configuration access URL's, so we can adjust the list to include a different filter chain for a different client

Code Block

	xml
	xml
title	Default security filtersxml

<bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      PATTERN_TYPE_APACHE_ANT
      /server/**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,jsonExceptionTranslationFilter,filterInvocationInterceptor
      /internal.html=httpSessionContextIntegrationFilter,ntlmProcessingFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
      /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor
    </value>
  </property>
</bean>

...

Versions Compared

Old Version 4

New Version Current

Key