Corrected links in manual, comment in schema file.
This commit is contained in:
parent
5a8772df5b
commit
24911eb606
|
@ -228,7 +228,7 @@ expression-handler =
|
|||
element expression-handler {ref}
|
||||
|
||||
custom-after-invocation-provider =
|
||||
## Used to decorate an AfterInvocationProvider to specify that it should be used with method security.
|
||||
## No longer supported. Use after-invocation-provider instead.
|
||||
element custom-after-invocation-provider {empty}
|
||||
|
||||
protect-pointcut =
|
||||
|
|
|
@ -161,9 +161,9 @@
|
|||
there is no preference. If this attribute is present on any
|
||||
<literal><intercept-url></literal> element, then a
|
||||
<classname>ChannelProcessingFilter</classname> will be added to the filter stack and its
|
||||
additional dependencies added to the application context. See the chapter on <link
|
||||
additional dependencies added to the application context. <!--See the chapter on <link
|
||||
xlink:href="#channel-security-config">channel security</link> for an example
|
||||
configuration using traditional beans. </para>
|
||||
configuration using traditional beans. --></para>
|
||||
<para> If a <literal><port-mappings></literal> configuration is added, this will be
|
||||
used to by the <classname>SecureChannelProcessor</classname> and
|
||||
<classname>InsecureChannelProcessor</classname> beans to determine the ports used for
|
||||
|
@ -423,7 +423,7 @@
|
|||
<section>
|
||||
<title>The <authentication-provider> Element</title>
|
||||
<para> This element is basically a shorthand syntax for configuring a <link
|
||||
xlink:href="#dao-provider"><classname>DaoAuthenticationProvider</classname></link>.
|
||||
xlink:href="#core-services-dao-provider"><classname>DaoAuthenticationProvider</classname></link>.
|
||||
<classname>DaoAuthenticationProvider</classname> loads user information from a
|
||||
<interfacename>UserDetailsService</interfacename> and compares the username/password
|
||||
combination with the values supplied at login. The
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
<interfacename>AccessDecisionManager</interfacename>. These crop up regularly throughout
|
||||
the remainder of this document so it's important you know how they are configured and how
|
||||
they operate. </para>
|
||||
<section xml:id="authentication-manager">
|
||||
<section xml:id="core-services-authentication-manager">
|
||||
<title>The <interfacename>AuthenticationManager</interfacename>,
|
||||
<classname>ProviderManager</classname> and
|
||||
<classname>AuthenticationProvider</classname>s</title>
|
||||
|
@ -74,7 +74,7 @@
|
|||
concerned about this, because if you forget to register a suitable provider, you'll
|
||||
simply receive a <literal>ProviderNotFoundException</literal> when an attempt to
|
||||
authenticate is made.</para>
|
||||
<section>
|
||||
<section xml:id="core-services-dao-provider">
|
||||
<title><literal>DaoAuthenticationProvider</literal></title>
|
||||
<para>The simplest <interfacename>AuthenticationProvider</interfacename> implemented by
|
||||
Spring Security is <literal>DaoAuthenticationProvider</literal>, which is is also
|
||||
|
@ -128,7 +128,7 @@
|
|||
should be easy for users to retrieve authentication information using a persistence
|
||||
strategy of their choice. Having said that, Spring Security does include a couple of
|
||||
useful base implementations, which we'll look at below.</para>
|
||||
<section xml:id="in-memory-service">
|
||||
<section xml:id="core-services-in-memory-service">
|
||||
<title>In-Memory Authentication</title>
|
||||
<para>Is easy to use create a custom <interfacename>UserDetailsService</interfacename>
|
||||
implementation that extracts information from a persistence engine of choice, but
|
||||
|
@ -137,7 +137,7 @@
|
|||
Security, when you don't really want to spend time configuring databases or writing
|
||||
<interfacename>UserDetailsService</interfacename> implementations. For this sort
|
||||
of situation, a simple option is to use the <literal>user-service</literal> element
|
||||
from the security <link xlink:href="#namespace-minimal">namespace</link>: <programlisting><![CDATA[
|
||||
from the security <link xlink:href="#ns-minimal">namespace</link>: <programlisting><![CDATA[
|
||||
<user-service id="userDetailsService">
|
||||
<user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
|
||||
<user name="bob" password="bobspassword" authorities="ROLE_USER" />
|
||||
|
@ -153,7 +153,7 @@
|
|||
jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled
|
||||
bob=bobspassword,ROLE_USER,enabled</programlisting></para>
|
||||
</section>
|
||||
<section xml:id="jdbc-service">
|
||||
<section xml:id="core-services-jdbc-user-service">
|
||||
<title><literal>JdbcDaoImpl</literal></title>
|
||||
<para>Spring Security also includes a <interfacename>UserDetailsService</interfacename>
|
||||
that can obtain authentication information from a JDBC data source. Internally
|
||||
|
|
|
@ -177,7 +177,7 @@
|
|||
application (which will be used for access control). It is also possible to load user
|
||||
information from a standard properties file using the <literal>properties</literal>
|
||||
attribute on <literal>user-service</literal>. See the section on <link
|
||||
xlink:href="#in-memory-service">in-memory authentication</link> for more details. Using
|
||||
xlink:href="#core-services-in-memory-service">in-memory authentication</link> for more details. Using
|
||||
the <literal><authentication-provider></literal> element means that the user
|
||||
information will be used by the authentication manager to process authentication requests. </para>
|
||||
<para> At this point you should be able to start up your application and you will be required
|
||||
|
@ -366,8 +366,8 @@
|
|||
<port-mapping http="9080" https="9443"/>
|
||||
</port-mappings>
|
||||
</http>]]>
|
||||
</programlisting> You can find a more in-depth discussion of channel security
|
||||
in <xref xlink:href="#channel-security"/>. </para>
|
||||
</programlisting> <!--You can find a more in-depth discussion of channel security
|
||||
in <xref xlink:href="#channel-security"/--> </para>
|
||||
</section>
|
||||
<section xml:id="ns-concurrent-session">
|
||||
<title>Concurrent Session Control</title>
|
||||
|
@ -569,7 +569,7 @@
|
|||
element. </para>
|
||||
<para> The CAS sample application is a good example of the use of custom beans with the
|
||||
namespace, including this syntax. If you aren't familiar with authentication entry points,
|
||||
they are discussed in the <link xlink:href="#tech-auth-entry-point">technical
|
||||
they are discussed in the <link xlink:href="#tech-intro-auth-entry-point">technical
|
||||
overview</link> chapter. </para>
|
||||
</section>
|
||||
</section>
|
||||
|
|
|
@ -111,7 +111,7 @@
|
|||
<section>
|
||||
<title>Http403ForbiddenEntryPoint</title>
|
||||
<para>
|
||||
The <interfacename>AuthenticationEntryPoint</interfacename> was discussed in the <link xlink:href="#tech-auth-entry-point">technical
|
||||
The <interfacename>AuthenticationEntryPoint</interfacename> was discussed in the <link xlink:href="#tech-intro-auth-entry-point">technical
|
||||
overview</link> chapter. Normally it is responsible for kick-starting the authentication process for an unauthenticated user
|
||||
(when they try to access a protected resource), but in the pre-authenticated case this doesn't apply. You would only
|
||||
configure the <classname>ExceptionTranslationFilter</classname> with an instance of this class if you aren't
|
||||
|
|
|
@ -19,7 +19,7 @@
|
|||
namespace configuration throughout. The compiled application is included in the
|
||||
distribution zip file, ready to be deployed into your web container
|
||||
(<filename>spring-security-samples-tutorial-3.0.x.war</filename>). The <link
|
||||
xlink:href="#form">form-based</link> authentication mechanism is used in combination
|
||||
xlink:href="#ns-form-and-basic">form-based</link> authentication mechanism is used in combination
|
||||
with the commonly-used <link xlink:href="#remember-me">remember-me</link> authentication
|
||||
provider to automatically remember the login using cookies.</para>
|
||||
<para>We recommend you start with the tutorial sample, as the XML is minimal and easy to
|
||||
|
@ -117,6 +117,6 @@ Success! Your web filters appear to be properly configured!
|
|||
xlink:href="#preauth">pre-authentication</link> framework to make use of login
|
||||
information from a J2EE container. The user name and roles are those setup by the
|
||||
container. </para>
|
||||
<para> The code is in <filename>samples/preauth</filename> . </para>
|
||||
<para> The code is in <filename>samples/preauth</filename>. </para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
|
|
@ -110,7 +110,7 @@
|
|||
<literal>false</literal> and servlet container lifecycle invocations are not delegated
|
||||
through <literal>DelegatingFilterProxy</literal>.</para>
|
||||
<para> When we looked at how to set up web security using <link
|
||||
xlink:href="#namespace-auto-config">namespace configuration</link>, we used a
|
||||
xlink:href="#ns-web-xml">namespace configuration</link>, we used a
|
||||
<literal>DelegatingFilterProxy</literal> with the name
|
||||
<quote>springSecurityFilterChain</quote>. You should now be able to see that this is the
|
||||
name of the <classname>FilterChainProxy</classname> which is created by the namespace. </para>
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
</author>
|
||||
</authorgroup>
|
||||
<productname>Spring Security</productname>
|
||||
<releaseinfo>3.0.0.M1</releaseinfo>
|
||||
<releaseinfo>3.0.0.M2</releaseinfo>
|
||||
</info>
|
||||
<toc/>
|
||||
<preface xml:id="preface">
|
||||
|
|
|
@ -111,7 +111,7 @@ if (principal instanceof UserDetails) {
|
|||
<para> On successful authentication, <interfacename>UserDetails</interfacename> is used to
|
||||
build the <interfacename>Authentication</interfacename> object that is stored in the
|
||||
<classname>SecurityContextHolder</classname> (more on this <link
|
||||
xlink:href="#tech-intro-authentication-mgr">below</link>). The good news is that we
|
||||
xlink:href="#tech-intro-authentication">below</link>). The good news is that we
|
||||
provide a number of <interfacename>UserDetailsService</interfacename> implementations,
|
||||
including one that uses an in-memory map (<classname>InMemoryDaoImpl</classname>) and
|
||||
another that uses JDBC (<classname>JdbcDaoImpl</classname>). Most users tend to
|
||||
|
@ -322,7 +322,7 @@ Successfully authenticated. Security context contains: \
|
|||
work, and still provide authorization capabilities. All you need to do is write a filter
|
||||
(or equivalent) that reads the third-party user information from a location, build a
|
||||
Spring Security-specific <interfacename>Authentication</interfacename> object, and put it
|
||||
onto the <classname>SecurityContextHolder</classname>.</para>
|
||||
into the <classname>SecurityContextHolder</classname>.</para>
|
||||
<para> If you're wondering how the <interfacename>AuthenticationManager</interfacename>
|
||||
manager is implemented in a real world example, we'll look at that in </para>
|
||||
</section>
|
||||
|
|
Loading…
Reference in New Issue