This is an automated email from the ASF dual-hosted git repository.
bmarwell pushed a commit to branch jbake
in repository https://gitbox.apache.org/repos/asf/shiro-site.git
The following commit(s) were added to refs/heads/jbake by this push:
new 2875aee fix and re-add anchors.
2875aee is described below
commit 2875aeef9ea9a83c707c404b6597340c0b5aa326
Author: Benjamin Marwell <[email protected]>
AuthorDate: Fri Jan 14 22:01:13 2022 +0100
fix and re-add anchors.
---
jbake/content/authorization.adoc | 2 +-
jbake/content/java-authentication-guide.adoc | 8 +++---
jbake/content/reference.adoc | 12 ++++----
jbake/content/session-management.adoc | 10 +++----
jbake/content/tutorial.adoc | 2 +-
jbake/content/web.adoc | 41 ++++++++++++++++++----------
6 files changed, 44 insertions(+), 31 deletions(-)
diff --git a/jbake/content/authorization.adoc b/jbake/content/authorization.adoc
index fc6c367..56008ff 100644
--- a/jbake/content/authorization.adoc
+++ b/jbake/content/authorization.adoc
@@ -502,7 +502,7 @@ public void updateAccount(Account account) {
[#Authentication-AuthorizingSubjects-JSPTagLibAuthorization]
=== JSP TagLib Authorization
-Shiro offers a Tag Library for controlling JSP/GSP page output based on
`Subject` state. This is covered in the link:web.html[Web] chapter's
link:web.html#Web-taglibrary[JSP/GSP Tag Library] section.
+Shiro offers a Tag Library for controlling JSP/GSP page output based on
`Subject` state. This is covered in the link:web.html[Web] chapter's
link:web.html#tag_library[JSP/GSP Tag Library] section.
[#Authentication-AuthorizingSequence]
== Authorization Sequence
diff --git a/jbake/content/java-authentication-guide.adoc
b/jbake/content/java-authentication-guide.adoc
index 7f373db..316edb3 100644
--- a/jbake/content/java-authentication-guide.adoc
+++ b/jbake/content/java-authentication-guide.adoc
@@ -62,7 +62,7 @@ In Shiro, it does not matter how you acquire them – it is
protocol agnostic.
In this example, we have decided that we want the application to remember
users when they return.
So once the token is created, we use Shiro's built-in "Remember-me" feature by
setting it to true on the token.
-This is done using the token's
link:++/static/current/apidocs/org/apache/shiro/authc/UsernamePasswordToken.html#setRememberMe-boolean-++[`setRememberMe()`]
method
+This is done using the token's
link:++/static/current/apidocs/org/apache/shiro/authc/UsernamePasswordToken.html#setRememberMe(boolean)++[`setRememberMe()`]
method
[#JavaAuthenticationGuide-Step2Submittheprincipalsandcredentialstoanauthenticationsystem]
=== Step 2 - Submit the principals and credentials to an authentication system.
@@ -88,12 +88,12 @@ currentUser.login(token);
First, we need to acquire the currently executing user, referred to as the
subject. A subject is just a security specific view of the user—-it can be a
human, a process, cron job, doesn't matter. In Shiro, there is always a subject
instance available to the currently executing thread. The concept of a subject
is core to Shiro and most of the framework is centered around working with
subjects. In this example, we will name this instance of subject currentUser.
To acquire the subject, we use the
link:/static/current/apidocs/org/apache/shiro/SecurityUtils.html[SecurityUtils]
class which is also a core part of Shiro's API.
-It will acquire the currently executing user via the
link:++/static/current/apidocs/org/apache/shiro/SecurityUtils.html#getSubject--++[`getsubject()`]
method call.
+It will acquire the currently executing user via the
link:++/static/current/apidocs/org/apache/shiro/SecurityUtils.html#getSubject()++[`getsubject()`]
method call.
And we get back a subject instance that is representing who the current user
is who is interacting with the system.
At this point in the example, the subject currentUser is anonymous.
There is no identity associated with them.
-Now with the user representation in hand, we authenticate them by just calling
the
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#login-org.apache.shiro.authc.AuthenticationToken-++[`login()`])
method and submit the token we just constructed a second ago.
+Now with the user representation in hand, we authenticate them by just calling
the
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#login(org.apache.shiro.authc.AuthenticationToken)++[`login()`])
method and submit the token we just constructed a second ago.
[#JavaAuthenticationGuide-Step3Allowaccessretryauthenticationorblockaccess]
=== Step 3 - Allow access, retry authentication, or block access
@@ -135,7 +135,7 @@ Security best practice is to give generic login failure
messages to users becaus
As shown in the example above, Shiro supports the notion of "remember me" in
addition to the normal login process.
-In Shiro, the Subject object supports two methods :
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#isRemembered--++[`isRemembered()`]
and
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#isAuthenticated--++[`isAuthenticated()`].
+In Shiro, the Subject object supports two methods :
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#isRemembered()++[`isRemembered()`]
and
link:++/static/current/apidocs/org/apache/shiro/subject/Subject.html#isAuthenticated()++[`isAuthenticated()`].
A "remembered" subject has an identity (it is not anonymous) and their
identifying attributes,referred to as principals, are remembered from a
successful authentication during a previous session.
diff --git a/jbake/content/reference.adoc b/jbake/content/reference.adoc
index 9abf792..05538dd 100644
--- a/jbake/content/reference.adoc
+++ b/jbake/content/reference.adoc
@@ -24,11 +24,11 @@
** link:web.html[Web]
-*** link:web.html#Web-configuration[Configuration]
-*** link:web.html#Web-webini[[urls] (Path-based security)]
-*** link:web.html#Web-defaultfilters[Default Filters]
-*** link:web.html#Web-sessionManagement[Session Management]
-*** link:web.html#Web-taglibrary[JSP Tag Library]
+*** link:web.html#configuration[Configuration]
+*** link:web.html#web_ini[urls] (Path-based security)]
+*** link:web.html#default_filters[Default Filters]
+*** link:web.html#session_management[Session Management]
+*** link:web.html#tag_library[JSP Tag Library]
. Auxiliary Support
@@ -49,4 +49,4 @@
. Index
-** link:terminology.html[Terminology]
\ No newline at end of file
+** link:terminology.html[Terminology]
diff --git a/jbake/content/session-management.adoc
b/jbake/content/session-management.adoc
index eabbc50..b11a011 100644
--- a/jbake/content/session-management.adoc
+++ b/jbake/content/session-management.adoc
@@ -401,7 +401,7 @@ One of the very exciting things about Apache Shiro's
session capabilities is tha
So how does it work?
-Because of Shiro's POJO-based N-tiered architecture, enabling Session
clustering is as simple as enabling a clustering mechanism at the Session
persistence level. That is, if you configure a cluster-capable
<<SessionManagement-sessionstorage,`SessionDAO`>>, the DAO can interact with a
clustering mechanism and Shiro's `SessionManager` never needs to know about
clustering concerns.
+Because of Shiro's POJO-based N-tiered architecture, enabling Session
clustering is as simple as enabling a clustering mechanism at the Session
persistence level. That is, if you configure a cluster-capable
<<SessionManagement-SessionManager-Storage,`SessionDAO`>>, the DAO can interact
with a clustering mechanism and Shiro's `SessionManager` never needs to know
about clustering concerns.
*Distributed Caches*
@@ -475,9 +475,9 @@ Then at runtime, when the `EnterpriseCacheSessionDAO` needs
the `activeSessionsC
One such distributed caching solution that people have had success with while
using Shiro is the Ehcache + Terracotta pairing. See the Ehcache-hosted
http://www.ehcache.org/documentation/get-started/about-distributed-cache[Distributed
Caching With Terracotta] documentation for full details of how to enable
distributed caching with Ehcache.
-Once you've got Terracotta clustering working with Ehcache, the Shiro-specific
parts are very simple. Read and follow the
<<SessionManagement-ehcachesessiondao,Ehcache SessionDAO>> documentation, but
we'll need to make a few changes
+Once you've got Terracotta clustering working with Ehcache, the Shiro-specific
parts are very simple. Read and follow the
<<SessionManagement-SessionManager-Storage-EHCacheSessionDAO,Ehcache
SessionDAO>> documentation, but we'll need to make a few changes
-The Ehcache Session Cache Configuration
<<SessionManagement-ehcachesessioncacheconfiguration,referenced previously>>
will not work - a Terracotta-specific configuration is needed. Here is an
example configuration that has been tested to work correctly. Save its contents
in a file and save it in an `ehcache.xml` file:
+The Ehcache Session Cache Configuration
<<SessionManagement-SessionManager-Storage-EHCacheSessionDAO-CacheConfiguration,referenced
previously>> will not work - a Terracotta-specific configuration is needed.
Here is an example configuration that has been tested to work correctly. Save
its contents in a file and save it in an `ehcache.xml` file:
*TerraCotta Session Clustering*
@@ -511,7 +511,7 @@ The Ehcache Session Cache Configuration
<<SessionManagement-ehcachesessioncachec
</ehcache>
----
-Of course you will want to change your `<terracottaConfig
url="localhost:9510"/>` entry to reference the appropriate
host/port of your Terracotta server array. Also notice that, unlike the
<<SessionManagement-ehcachesessioncacheconfiguration,previous>> configuration,
the `ehcache-activeSessionCache` element *_DOES NOT_* set `diskPersistent` or
`overflowToDisk` attributes to `true`. They should both be `false` as true
values are not supported in clustered configuration.
+Of course you will want to change your `<terracottaConfig
url="localhost:9510"/>` entry to reference the appropriate
host/port of your Terracotta server array. Also notice that, unlike the
<<SessionManagement-SessionManager-Storage-EHCacheSessionDAO-CacheConfiguration,previous>>
configuration, the `ehcache-activeSessionCache` element *_DOES NOT_* set
`diskPersistent` or `overflowToDisk` attributes to `true`. They should both be
`false` as true values are not supported in [...]
After you've saved this `ehcache.xml` file, we'll need to reference it in
Shiro's configuration. Assuming you've made the terracotta-specific
`ehcache.xml` file accessible at the root of the classpath, here is the final
Shiro configuration that enables Terracotta+Ehcache clustering for all of
Shiro's needs (including Sessions):
@@ -701,4 +701,4 @@ If a `Subject` already has a session prior to visiting the
noSessionCreation-pro
Finally, the following calls will always be allowed in all cases:
* `httpServletRequest.getSession(false)`
-* `subject.getSession(false)`
\ No newline at end of file
+* `subject.getSession(false)`
diff --git a/jbake/content/tutorial.adoc b/jbake/content/tutorial.adoc
index 961a617..61ff0ce 100644
--- a/jbake/content/tutorial.adoc
+++ b/jbake/content/tutorial.adoc
@@ -268,7 +268,7 @@ In almost all environments, you can obtain the currently
executing user via the
Subject currentUser = SecurityUtils.getSubject();
----
-Using
link:static/current/apidocs/org/apache/shiro/SecurityUtils.html[`SecurityUtils`].link:static/current/apidocs/org/apache/shiro/SecurityUtils.html#getSubject--[getSubject()],
we can obtain the currently executing
link:static/current/apidocs/org/apache/shiro/subject/Subject.html[`Subject`].
_Subject_ is a security term that basically means "a security-specific view of
the currently executing user". It is not called a 'User' because the word
'User' is usually associated with a human be [...]
+Using
link:static/current/apidocs/org/apache/shiro/SecurityUtils.html[`SecurityUtils`].link:static/current/apidocs/org/apache/shiro/SecurityUtils.html#getSubject()[getSubject()],
we can obtain the currently executing
link:static/current/apidocs/org/apache/shiro/subject/Subject.html[`Subject`].
_Subject_ is a security term that basically means "a security-specific view of
the currently executing user". It is not called a 'User' because the word
'User' is usually associated with a human be [...]
The `getSubject()` call in a standalone application might return a `Subject`
based on user data in an application-specific location, and in a server
environment (e.g. web app), it acquires the `Subject` based on user data
associated with current thread or incoming request.
diff --git a/jbake/content/web.adoc b/jbake/content/web.adoc
index f706489..3e7eef2 100644
--- a/jbake/content/web.adoc
+++ b/jbake/content/web.adoc
@@ -7,14 +7,15 @@
:toc:
:toclevels: 5
+[#configuration]
== Configuration
-The simplest way to integrate Shiro into any web application is to configure a
Servlet ContextListener and Filter in web.xml that understands how to read
Shiro's INI configuration. The bulk of the INI config format itself is defined
in the Configuration pages's
link:configuration.html#[[#]]#Configuration-INISections[INI Sections] section,
but we'll cover some additional web-specific sections here.
+The simplest way to integrate Shiro into any web application is to configure a
Servlet ContextListener and Filter in web.xml that understands how to read
Shiro's INI configuration. The bulk of the INI config format itself is defined
in the Configuration pages's
link:/configuration.html#Configuration-INIConfiguration-Sections[INI Sections]
section, but we'll cover some additional web-specific sections here.
[INFO]
.Using Spring?
====
-Spring Framework users will not perform this setup. If you use Spring, you
will want to read about link:spring-boot.html#web-applications[Spring-specific
web configuration] instead.
+Spring Framework users will not perform this setup. If you use Spring, you
will want to read about link:/spring-boot.html#web_applications[Spring-specific
web configuration] instead.
====
=== `web.xml`
@@ -209,6 +210,7 @@ Inline config is often fine for small or simple
applications, but it is usually
It is up to you - use what makes sense for your project.
+[#web_ini]
=== Web INI configuration
In addition to the standard `[main]`, `[users]` and `[roles]` sections already
described in the main link:configuration.html[Configuration] chapter, you can
additionally specify a web-specific `[urls]` section in your `shiro.ini` file:
@@ -326,6 +328,7 @@ myFilter.property1 = value1
/some/path/** = myFilter
----
+[#default_filters]
== Default Filters
When running a web-app, Shiro will create some useful default `Filter`
instances and make them available in the `[main]` section automatically. You
can configure them in `main` as you would any other bean and reference them in
your chain definitions. For example:
@@ -482,6 +485,7 @@ ssl.hsts.includeSubDomains = true
...
----
+[#session_management]
== Session Management
=== Servlet Container Sessions
@@ -533,7 +537,7 @@ Once declared, you can configure the
`DefaultWebSessionManager` instance with na
===== Native Session Timeout
-After configuring the `DefaultWebSessionManager` instance, session timeout is
configured as described in
link:session-management.html#[[#]]#SessionManagement-sessionTimeout[Session
Management: Session Timeout]
+After configuring the `DefaultWebSessionManager` instance, session timeout is
configured as described in
link:/session-management.html#SessionManagement-SessionManager-SessionTimeout[Session
Management: Session Timeout]
===== Session Cookie
@@ -685,11 +689,12 @@ rememberMeManager = com.my.impl.RememberMeManager
securityManager.rememberMeManager = $rememberMeManager
----
+[#tag_library]
== JSP / GSP Tag Library
Apache Shiro provides a `Subject`-aware JSP/GSP tag library that allows you to
control your JSP, JSTL or GSP page output based on the current Subject's state.
This is quite useful for personalizing views based on the identity and
authorization state of the current user viewing the web page.
-===Tag Library Configuration
+=== Tag Library Configuration
The Tag Library Descriptor (TLD) file is bundled in `shiro-web.jar` in the
`META-INF/shiro.tld` file. To use any of the tags, add the following line to
the top of your JSP page (or wherever you define page directives):
@@ -702,6 +707,7 @@ We've used the `shiro` prefix to indicate the shiro tag
library namespace, but y
Now we'll cover each tag and show how it might be used to render a page.
+[#web_guesttag]
=== The `guest` tag
The `guest` tag will display its wrapped content only if the current `Subject`
is considered a 'guest'. A guest is any `Subject` that does not have an
identity. That is, we don't know who the user is because they have not logged
in and they are not remembered (from Remember Me services) from a previous site
visit.
@@ -715,11 +721,12 @@ Example:
</shiro:guest>
----
-The `guest` tag is the logical opposite of the <<Web-usertag,`user`>> tag.
+The `guest` tag is the logical opposite of the <<web_usertag,`user`>> tag.
+[#web_usertag]
=== The `user` tag
-The `user` tag will display its wrapped content only if the current `Subject`
is considered a 'user'. A 'user' in this context is defined as a `Subject` with
a known identity, either from a successful authentication or from 'RememberMe'
services. Note that this tag is semantically different from the
<<Web-authenticatedtag,authenticated>> tag, which is more restrictive than this
tag.
+The `user` tag will display its wrapped content only if the current `Subject`
is considered a 'user'. A 'user' in this context is defined as a `Subject` with
a known identity, either from a successful authentication or from 'RememberMe'
services. Note that this tag is semantically different from the
<<web_authenticatedtag,authenticated>> tag, which is more restrictive than this
tag.
Example:
@@ -730,13 +737,14 @@ Example:
</shiro:user>
----
-The `user` tag is the logical opposite of the <<Web-guesttag,`guest`>> tag.
+The `user` tag is the logical opposite of the <<web_guesttag,`guest`>> tag.
+[#web_authenticatedtag]
=== The `authenticated` tag
Displays body content only if the current user has successfully authenticated
_during their current session_. It is more restrictive than the 'user' tag. It
is logically opposite to the 'notAuthenticated' tag.
-The `authenticated` tag will display its wrapped content only if the current
`Subject` has successfully authenticated _during their current session_. It is
a more restrictive tag than the <<Web-usertag,user>>, which is used to
guarantee identity in sensitive workflows.
+The `authenticated` tag will display its wrapped content only if the current
`Subject` has successfully authenticated _during their current session_. It is
a more restrictive tag than the <<web_usertag,user>>, which is used to
guarantee identity in sensitive workflows.
Example:
@@ -747,8 +755,9 @@ Example:
</shiro:authenticated>
----
-The `authenticated` tag is the logical opposite of the
<<Web-notauthenticatedtag,`notAuthenticated`>> tag.
+The `authenticated` tag is the logical opposite of the
<<web_notauthenticatedtag,`notAuthenticated`>> tag.
+[#web_notauthenticatedtag]
=== The `notAuthenticated` tag
The `notAuthenticated` tag will display its wrapped content if the current
`Subject` has *NOT* yet successfully authenticated during the current session.
@@ -762,7 +771,7 @@ Example:
</shiro:notAuthenticated>
----
-The `notAuthenticated` tag is the logical opposite of the
<<Web-authenticatedtag,`authenticated`>> tag.
+The `notAuthenticated` tag is the logical opposite of the
<<web_authenticatedtag,`authenticated`>> tag.
=== The `principal` tag
@@ -830,6 +839,7 @@ this is largely equivalent to the following:
Hello, <%=
SecurityUtils.getSubject().getPrincipals().oneByType(com.foo.User.class).getFirstName().toString()
%>, how are you today?
----
+[#web_hasroletag]
=== The `hasRole` tag
The `hasRole` tag will display its wrapped content only if the current
`Subject` is assigned the specified role.
@@ -843,8 +853,9 @@ For example:
</shiro:hasRole>
----
-The `hasRole` tag is the logical opposite of the
<<Web-lacksroletag,lacksRole>> tag.
+The `hasRole` tag is the logical opposite of the
<<web_lacksroletag,lacksRole>> tag.
+[#web_lacksroletag]
=== The `lacksRole` tag
The `lacksRole` tag will display its wrapped content only if the current
`Subject` *is NOT* assigned the specified role.
@@ -858,7 +869,7 @@ For example:
</shiro:lacksRole>
----
-The `lacksRole` tag is the logical opposite of the <<Web-hasroletag,hasRole>>
tag.
+The `lacksRole` tag is the logical opposite of the <<web_hasroletag,hasRole>>
tag.
=== The `hasAnyRole` tag
@@ -875,6 +886,7 @@ For example:
The `hasAnyRole` tag does not currently have a logically opposite tag.
+[#web_haspermissiontag]
=== The `hasPermission` tag
The `hasPermission` tag will display its wrapped content only if the current
`Subject` 'has' (implies) the specified permission. That is, the user has the
specified ability.
@@ -888,8 +900,9 @@ For example:
</shiro:hasPermission>
----
-The `hasPermission` tag is the logical opposite of the
<<Web-lackspermissiontag,lacksPermission>> tag.
+The `hasPermission` tag is the logical opposite of the
<<web_lackspermissiontag,lacksPermission>> tag.
+[#web_lackspermissiontag]
=== The `lacksPermission` tag
The `lacksPermission` tag will display its wrapped content only if the current
`Subject` *DOES NOT* have (imply) the specified permission. That is, the user
*DOES NOT* have the specified ability.
@@ -903,7 +916,7 @@ For example:
</shiro:lacksPermission>
----
-The `lacksPermission` tag is the logical opposite of the
<<Web-haspermissiontag,hasPermission>> tag.
+The `lacksPermission` tag is the logical opposite of the
<<web_haspermissiontag,hasPermission>> tag.
++++
<@lendahand.lendahand />
