You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@shiro.apache.org by bd...@apache.org on 2016/10/24 14:33:53 UTC
svn commit: r1766414 [9/16] - /shiro/site/publish/
Modified: shiro/site/publish/overview.html
URL: http://svn.apache.org/viewvc/shiro/site/publish/overview.html?rev=1766414&r1=1766413&r2=1766414&view=diff
==============================================================================
--- shiro/site/publish/overview.html (original)
+++ shiro/site/publish/overview.html Mon Oct 24 14:33:52 2016
@@ -78,112 +78,88 @@
<div id="content">
- <h1><a name="Overview-OverviewofApacheShiro"></a>Overview of Apache Shiro</h1>
-
-<h2><a name="Overview-Introduction"></a>Introduction</h2>
-
+ <a name="Overview-OverviewofApacheShiro"></a>
+<h1><a href="#overview-of-apache-shiro" name="overview-of-apache-shiro">Overview of Apache Shiro</a></h1>
+<a name="Overview-Introduction"></a>
+<h2><a href="#introduction" name="introduction">Introduction</a></h2>
<p>Apache Shiro is a powerful and flexible open-source security framework that cleanly handles authentication, authorization, enterprise session management and cryptography.</p>
-
-<p>Apache Shiro's first and foremost goal is to be easy to use and understand. Security can be very complex at times, even painful, but it doesn't have to be. A framework should mask complexities where possible and expose a clean and intuitive API that simplifies the developer's effort to make their application(s) secure.</p>
-
+<p>Apache Shiro’s first and foremost goal is to be easy to use and understand. Security can be very complex at times, even painful, but it doesn’t have to be. A framework should mask complexities where possible and expose a clean and intuitive API that simplifies the developer’s effort to make their application(s) secure.</p>
<p>Here are some things that you can do with Apache Shiro:</p>
-
-<ul><li>Authenticate a user to verify their identity</li><li>Perform access control for a user, such as:
- <ul><li>Determine if a user is assigned a certain security role or not</li><li>Determine if a user is permitted to do something or not</li></ul>
- </li><li>Use a Session API in any environment, even without web or EJB containers.</li><li>React to events during authentication, access control, or during a session's lifetime.</li><li>Aggregate 1 or more data sources of user security data and present this all as a single composite user 'view'.</li><li>Enable Single Sign On (SSO) functionality</li><li>Enable 'Remember Me' services for user association without login<br clear="none">
-...<br clear="none">
-and much more - all integrated into a cohesive easy-to-use API.</li></ul>
-
-
-<p>Shiro attempts to achieve these goals for all application environments - from the simplest command line application to the largest enterprise applications, without forcing dependencies on other 3rd party frameworks, containers, or application servers. Of course the project aims to integrate into these environments wherever possible, but it could be used out-of-the-box in any environment.</p>
-
-<h2><a name="Overview-Features"></a>Features</h2>
-
-<p>Apache Shiro is a comprehensive application security framework with many features. The following diagram shows where Shiro focuses its energy, and this reference manual will be organized similarly:</p>
-
-<p><br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline">
-<span class="image-wrap" style="display: block; text-align: center"><img src="overview.data/ShiroFeatures.png" style="border: 0px solid black"></span>
-<br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline"></p>
-
-<p>Shiro targets what the Shiro development team calls "the four cornerstones of application security" - Authentication, Authorization, Session Management, and Cryptography:</p>
-
-<ul><li><b>Authentication:</b> Sometimes referred to as 'login', this is the act of proving a user is who they say they are.
-<br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline"></li><li><b>Authorization:</b> The process of access control, i.e. determining 'who' has access to 'what'.
-<br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline"></li><li><b>Session Management:</b> Managing user-specific sessions, even in non-web or EJB applications.
-<br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline"></li><li><b>Cryptography:</b> Keeping data secure using cryptographic algorithms while still being easy to use.</li></ul>
-
-
+<ul>
+ <li>Authenticate a user to verify their identity</li>
+ <li>Perform access control for a user, such as:
+ <ul>
+ <li>Determine if a user is assigned a certain security role or not</li>
+ <li>Determine if a user is permitted to do something or not</li>
+ </ul>
+ </li>
+ <li>Use a Session API in any environment, even without web or EJB containers.</li>
+ <li>React to events during authentication, access control, or during a session’s lifetime.</li>
+ <li>Aggregate 1 or more data sources of user security data and present this all as a single composite user ‘view’.</li>
+ <li>Enable Single Sign On (SSO) functionality</li>
+ <li>Enable ‘Remember Me’ services for user association without login<br/>…<br/>and much more - all integrated into a cohesive easy-to-use API.</li>
+</ul>
+<p>Shiro attempts to achieve these goals for all application environments - from the simplest command line application to the largest enterprise applications, without forcing dependencies on other 3rd party frameworks, containers, or application servers. Of course the project aims to integrate into these environments wherever possible, but it could be used out-of-the-box in any environment.</p>
+<a name="Overview-Features"></a>
+<h2><a href="#features" name="features">Features</a></h2>
+<p>Apache Shiro is a comprehensive application security framework with many features. The following diagram shows where Shiro focuses its energy, and this reference manual will be organized similarly:</p>
+<img src="assets/images/ShiroFeatures.png" style="margin:0px auto;display:block"></img>
+<p>Shiro targets what the Shiro development team calls “the four cornerstones of application security” - Authentication, Authorization, Session Management, and Cryptography:</p>
+<ul>
+ <li>
+ <p><strong>Authentication:</strong> Sometimes referred to as ‘login’, this is the act of proving a user is who they say they are.</p></li>
+ <li>
+ <p><strong>Authorization:</strong> The process of access control, i.e. determining ‘who’ has access to ‘what’.</p></li>
+ <li>
+ <p><strong>Session Management:</strong> Managing user-specific sessions, even in non-web or EJB applications.</p></li>
+ <li>
+ <p><strong>Cryptography:</strong> Keeping data secure using cryptographic algorithms while still being easy to use.</p></li>
+</ul>
<p>There are also additional features to support and reinforce these concerns in different application environments, especially:</p>
-
-<ul><li>Web Support: Shiro's web support APIs help easily secure web applications.</li><li>Caching: Caching is a first-tier citizen in Apache Shiro's API to ensure that security operations remain fast and efficient.</li><li>Concurrency: Apache Shiro supports multi-threaded applications with its concurrency features.</li><li>Testing: Test support exists to help you write unit and integration tests and ensure your code will be secured as expected.</li><li>"Run As": A feature that allows users to assume the identity of another user (if they are allowed), sometimes useful in administrative scenarios.</li><li>"Remember Me": Remember users' identities across sessions so they only need to log in when mandatory.</li></ul>
-
-
-<p></p>
-
-<h2><a name="Overview-AFirstLookatApacheShiro"></a>A First Look at Apache Shiro</h2>
-
-<p>Apache Shiro's design goals are to simplify application security by being intuitive and easy to use. Shiro's core design models how most people think about application security - in the context of someone (or something) interacting with an application.</p>
-
-<p>Software applications are usually designed based on user stories. That is, you'll often design user interfaces or service APIs based on how a user would (or should) interact with the software. For example, you might say, "If the user interacting with my application is logged in, I will show them a button they can click to view their account information. If they are not logged in, I will show a sign-up button." </p>
-
-<p>This example statement indicates that applications are largely written to satisfy user requirements and needs. Even if the 'user' is another software system and not a human being, you still write code to reflect behavior based on who (or what) is currently interacting with your software.</p>
-
+<ul>
+ <li>Web Support: Shiro’s web support APIs help easily secure web applications.</li>
+ <li>Caching: Caching is a first-tier citizen in Apache Shiro’s API to ensure that security operations remain fast and efficient.</li>
+ <li>Concurrency: Apache Shiro supports multi-threaded applications with its concurrency features.</li>
+ <li>Testing: Test support exists to help you write unit and integration tests and ensure your code will be secured as expected.</li>
+ <li>“Run As”: A feature that allows users to assume the identity of another user (if they are allowed), sometimes useful in administrative scenarios.</li>
+ <li>“Remember Me”: Remember users’ identities across sessions so they only need to log in when mandatory.</li>
+</ul>
+<a name="Overview-AFirstLookatApacheShiro"></a>
+<h2><a href="#a-first-look-at-apache-shiro" name="a-first-look-at-apache-shiro">A First Look at Apache Shiro</a></h2>
+<p>Apache Shiro’s design goals are to simplify application security by being intuitive and easy to use. Shiro’s core design models how most people think about application security - in the context of someone (or something) interacting with an application.</p>
+<p>Software applications are usually designed based on user stories. That is, you’ll often design user interfaces or service APIs based on how a user would (or should) interact with the software. For example, you might say, “If the user interacting with my application is logged in, I will show them a button they can click to view their account information. If they are not logged in, I will show a sign-up button.”</p>
+<p>This example statement indicates that applications are largely written to satisfy user requirements and needs. Even if the ‘user’ is another software system and not a human being, you still write code to reflect behavior based on who (or what) is currently interacting with your software.</p>
<p>Shiro largely reflects these concepts in its own design. By matching what is already intuitive for software developers, Apache Shiro remains intuitive and easy to use in practically any application.</p>
-
-<h3><a name="Overview-BasicDesign"></a>Basic Design</h3>
-
-<p>Shiro's architecture has 3 primary concepts: the <tt>Subject</tt>, <tt>SecurityManager</tt> and <tt>Realm</tt> s. The following diagram is a high-level overview of how these concepts interact, and we'll cover each concept below:</p>
-
-<p><br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline">
-<span class="image-wrap" style="display: block; text-align: center"><img src="overview.data/ShiroBasicArchitecture.png" style="border: 0px solid black"></span>
-<br clear="none" class="atl-forced-newline">
-<br clear="none" class="atl-forced-newline"></p>
-
-<h4><a name="Overview-Subject"></a>Subject</h4>
-
-<p>The <tt>Subject</tt> is essentially a security specific 'view' of the the currently executing user. Notice that it is not actually named <em>User</em> however. The name <em>Subject</em> was chosen for two reasons: </p>
-
-<ol><li>The word 'User' often implies a human being in many software systems. But sometimes the 'currently executing user' isn't a human being at all - maybe it is a 3rd-party process or remote server or daemon account. The word 'Subject' is more general and can mean 'the entity interacting with the software'.</li><li>The word 'Subject', because it is a general-purpose concept, is the actual term most often used in the security world. We retain that definition to be consistent.</li></ol>
-
-
-<p>You can acquire the current <tt>Subject</tt> anywhere in your application code as shown here:</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-<span class="code-keyword">import</span> org.apache.shiro.subject.Subject;
-<span class="code-keyword">import</span> org.apache.shiro.SecurityUtils;
+<a name="Overview-BasicDesign"></a>
+<h3><a href="#basic-design" name="basic-design">Basic Design</a></h3>
+<p>Shiro’s architecture has 3 primary concepts: the <code>Subject</code>, <code>SecurityManager</code> and <code>Realm</code> s. The following diagram is a high-level overview of how these concepts interact, and we’ll cover each concept below:</p>
+<img src="assets/images/ShiroBasicArchitecture.png" style="margin:0px auto;display:block"></img>
+<a name="Overview-Subject"></a>
+<h4><a href="#subject" name="subject">Subject</a></h4>
+<p>The <code>Subject</code> is essentially a security specific ‘view’ of the the currently executing user. Notice that it is not actually named <em>User</em> however. The name <em>Subject</em> was chosen for two reasons:</p>
+<ol>
+ <li>The word ‘User’ often implies a human being in many software systems. But sometimes the ‘currently executing user’ isn’t a human being at all - maybe it is a 3rd-party process or remote server or daemon account. The word ‘Subject’ is more general and can mean ‘the entity interacting with the software’.</li>
+ <li>The word ‘Subject’, because it is a general-purpose concept, is the actual term most often used in the security world. We retain that definition to be consistent.</li>
+</ol>
+<p>You can acquire the current <code>Subject</code> anywhere in your application code as shown here:</p>
+<pre><code class="java">import org.apache.shiro.subject.Subject;
+import org.apache.shiro.SecurityUtils;
...
Subject currentUser = SecurityUtils.getSubject();
-</pre>
-</div></div>
-
-<p>Once you have a <tt>Subject</tt> instance, you immediately have access to 90% of everything you would ever need to do to perform security for that Subject, such as login and logout, perform role and permission checks, access their session, and more - but more about this later. The most important thing to know is that the <tt>Subject</tt> is your 'security-specific view' of an application 'user' and that you can essentially access this anywhere in application code to perform whatever security operations you need. </p>
-
-<h4><a name="Overview-TheSecurityManager"></a>The SecurityManager</h4>
-
-<p>While application developers almost exclusively interact with <tt>Subject</tt> instances in their code, Subjects have a 'behind the scenes' counterpart that makes them work - the Shiro <tt>SecurityManager</tt> (note this is <em>not</em> the same thing as the <tt>java.lang.SecurityManager</tt>).</p>
-
-<p>While a <tt>Subject</tt> instance represents security information and operations for a single user, the Shiro <tt>SecurityManager</tt> manages security operations for <em>all</em> users. It is essentially the 'man behind the curtain' that manages all features in Shiro for all Subjects. Each software application that uses Shiro typically has one and only one <tt>SecurityManager</tt> instance.</p>
-
-<p>The <tt>SecurityManager</tt> is the heart of Shiro’s architecture and acts as a sort of 'umbrella’ object that coordinates internally nested security components that form an object graph. However, once the SecurityManager and its internal object graph is configured, it is usually left alone and application developers spend almost all of their time with the <tt>Subject</tt> API.</p>
-
-<p>We will talk about the <tt>SecurityManager</tt> in detail later on, but it is important to realize that when you interact with a <tt>Subject</tt>, it is really the <tt>SecurityManager</tt> behind the scenes that does all the heavy lifting for any <tt>Subject</tt> security operation. This is reflected in the basic flow diagram above.</p>
-
-<h4><a name="Overview-Realms"></a>Realms</h4>
-
-<p>The third and final core concept in Shiro is that of a Realm. A Realm acts as the ‘bridge’ or ‘connector’ between Shiro and your application’s security data. That is, when it comes time to actually interact with security-related data like user accounts to perform authentication (login) and authorization (access control), Shiro looks up many of these things from one or more Realms configured for an application.</p>
-
-<p>In this sense a Realm is essentially a security-specific <a class="external-link" href="https://en.wikipedia.org/wiki/Data_access_object" rel="nofollow">DAO</a>: it encapsulates connection details for data sources and makes the associated data available to Shiro as needed. When configuring Shiro, you must specify at least one Realm to use for authentication and/or authorization. More than one Realm may be configured, but at least one is required.</p>
-
+</code></pre>
+<p>Once you have a <code>Subject</code> instance, you immediately have access to 90% of everything you would ever need to do to perform security for that Subject, such as login and logout, perform role and permission checks, access their session, and more - but more about this later. The most important thing to know is that the <code>Subject</code> is your ‘security-specific view’ of an application ‘user’ and that you can essentially access this anywhere in application code to perform whatever security operations you need.</p>
+<a name="Overview-TheSecurityManager"></a>
+<h4><a href="#the-securitymanager" name="the-securitymanager">The SecurityManager</a></h4>
+<p>While application developers almost exclusively interact with <code>Subject</code> instances in their code, Subjects have a ‘behind the scenes’ counterpart that makes them work - the Shiro <code>SecurityManager</code> (note this is <em>not</em> the same thing as the <code>java.lang.SecurityManager</code>).</p>
+<p>While a <code>Subject</code> instance represents security information and operations for a single user, the Shiro <code>SecurityManager</code> manages security operations for <em>all</em> users. It is essentially the ‘man behind the curtain’ that manages all features in Shiro for all Subjects. Each software application that uses Shiro typically has one and only one <code>SecurityManager</code> instance.</p>
+<p>The <code>SecurityManager</code> is the heart of Shiro’s architecture and acts as a sort of ’umbrella’ object that coordinates internally nested security components that form an object graph. However, once the SecurityManager and its internal object graph is configured, it is usually left alone and application developers spend almost all of their time with the <code>Subject</code> API.</p>
+<p>We will talk about the <code>SecurityManager</code> in detail later on, but it is important to realize that when you interact with a <code>Subject</code>, it is really the <code>SecurityManager</code> behind the scenes that does all the heavy lifting for any <code>Subject</code> security operation. This is reflected in the basic flow diagram above.</p>
+<a name="Overview-Realms"></a>
+<h4><a href="#realms" name="realms">Realms</a></h4>
+<p>The third and final core concept in Shiro is that of a Realm. A Realm acts as the ‘bridge’ or ‘connector’ between Shiro and your application’s security data. That is, when it comes time to actually interact with security-related data like user accounts to perform authentication (login) and authorization (access control), Shiro looks up many of these things from one or more Realms configured for an application.</p>
+<p>In this sense a Realm is essentially a security-specific <a href="https://en.wikipedia.org/wiki/Data_access_object">DAO</a>: it encapsulates connection details for data sources and makes the associated data available to Shiro as needed. When configuring Shiro, you must specify at least one Realm to use for authentication and/or authorization. More than one Realm may be configured, but at least one is required.</p>
<p>Shiro provides out-of-the-box Realms to connect to a number of security data sources (aka directories) such as LDAP, relational databases (JDBC), text configuration sources like INI and properties files, and more. You can plug-in your own Realm implementations to represent custom data sources if the default Realms do not meet your needs.</p>
-
-<p>Like other internal components, the Shiro <tt>SecurityManager</tt> manages how Realms are used to acquire security data and then represented as <tt>Subject</tt> instances.</p>
+<p>Like other internal components, the Shiro <code>SecurityManager</code> manages how Realms are used to acquire security data and then represented as <code>Subject</code> instances.</p>
</div>
Modified: shiro/site/publish/permissions.html
URL: http://svn.apache.org/viewvc/shiro/site/publish/permissions.html?rev=1766414&r1=1766413&r2=1766414&view=diff
==============================================================================
--- shiro/site/publish/permissions.html (original)
+++ shiro/site/publish/permissions.html Mon Oct 24 14:33:52 2016
@@ -79,332 +79,181 @@
<div id="content">
<h1><a name="Permissions-UnderstandingPermissionsinApacheShiro"></a>Understanding Permissions in Apache Shiro</h1>
+<table align="right" width="275" style="margin-left: 20px; margin-bottom: 20px; border-style: solid; border-width: 2px; border-color: navy" cellpadding="10px"><tbody><tr><td>
-<table align="right" width="275" style="margin-left: 20px; margin-bottom: 20px; border-style: solid; border-width: 2px; border-color: navy" cellpadding="10px">
-
-<tr>
-<td>
<div id="border">
- <h2>Related Content</h2>
-
- <h3><a href="java-authorization-guide.html">Java Authorization Guide</a></h3>
- <p>Learn how Shiro handles access control in Java. </br><span style="font-size:11"><a href="java-authorization-guide.html">Read More >></a></span></p>
-
- <h3><a href="webapp-tutorial.html">Web App Tutorial</a></h3>
- <p>Step-by-step tutorial for securing a web application with Shiro. </br><span style="font-size:11"><a href="webapp-tutorial.html">Read More >></a></span></p>
-
- <h3><a href="get-started.html">Getting Started</a></h3>
- <p>Resources, guides and tutorials for new Shiro users. </br><span style="font-size:11"><a href="get-started.html">Read More >></a></span></p>
-
- <h3><a href="10-minute-tutorial.html">10-Minute Shiro Tutorial</a></h3>
- <p>Try Apache Shiro for yourself in under 10 minutes. </br><span style="font-size:11"><a href="10-minute-tutorial.html">Read More >></a></span></p>
-
-</div>
-</td>
-</tr>
-</table>
+ <h2>Related Content</h2>
-<p>Shiro defines a Permission as a statement that defines an explicit behavior or action. It is a statement of raw functionality in an application and nothing more. Permissions are the lowest-level constructs in security polices, and they explicitly define only "what" the application can do.</p>
+ <h3><a href="java-authorization-guide.html">Java Authorization Guide</a></h3>
+ <p>Learn how Shiro handles access control in Java. <br><span style="font-size:11"><a href="java-authorization-guide.html">Read More >></a></span></p>
-<p>They do <em>not</em> at all describe "who" is able to perform the action(s).</p>
+ <h3><a href="webapp-tutorial.html">Web App Tutorial</a></h3>
+ <p>Step-by-step tutorial for securing a web application with Shiro. <br><span style="font-size:11"><a href="webapp-tutorial.html">Read More >></a></span></p>
-<p>Some examples of permissions:</p>
-<ul><li>Open a file</li><li>View the '/user/list' web page</li><li>Print documents</li><li>Delete the 'jsmith' user</li></ul>
+ <h3><a href="get-started.html">Getting Started</a></h3>
+ <p>Resources, guides and tutorials for new Shiro users. <br><span style="font-size:11"><a href="get-started.html">Read More >></a></span></p>
+ <h3><a href="10-minute-tutorial.html">10-Minute Shiro Tutorial</a></h3>
+ <p>Try Apache Shiro for yourself in under 10 minutes. <br><span style="font-size:11"><a href="10-minute-tutorial.html">Read More >></a></span></p>
-<p>Defining "who" (users) is allowed to do "what" (permissions) is an exercise of assigning permissions to users in some way. This is always done by the application's data model and can vary greatly across applications. </p>
-
-<p>For example, permissions can be grouped in a Role and that Role could be associated with one or more User objects. Or some applications can have a Group of users and a Group can be assigned a Role, which by transitive association would mean that all the Users in that Group are implicitly granted the permissions in the Role.</p>
+</div>
+</td></tr></tbody></table>
+<p>Shiro defines a Permission as a statement that defines an explicit behavior or action. It is a statement of raw functionality in an application and nothing more. Permissions are the lowest-level constructs in security polices, and they explicitly define only “what” the application can do.</p>
+<p>They do <em>not</em> at all describe “who” is able to perform the action(s).</p>
+<p>Some examples of permissions:</p>
+<ul>
+ <li>Open a file</li>
+ <li>View the ‘/user/list’ web page</li>
+ <li>Print documents</li>
+ <li>Delete the ‘jsmith’ user</li>
+</ul>
+<p>Defining “who” (users) is allowed to do “what” (permissions) is an exercise of assigning permissions to users in some way. This is always done by the application’s data model and can vary greatly across applications.</p>
+<p>For example, permissions can be grouped in a Role and that Role could be associated with one or more User objects. Or some applications can have a Group of users and a Group can be assigned a Role, which by transitive association would mean that all the Users in that Group are implicitly granted the permissions in the Role.</p>
<p>There are many variations for how permissions could be granted to users - the application determines how to model this based on the application requirements.</p>
-
-<h2><a name="Permissions-WildcardPermissions"></a>Wildcard Permissions</h2>
-
-<p>The above examples of permissions, "Open a file", "View the 'user/list' web page", etc are all valid permission statements. However, it would be very difficult computationally to interpret those natural language strings and determine if a user is allowed to perform that behavior or not.</p>
-
+<a name="Permissions-WildcardPermissions"></a>
+<h2><a href="#wildcard-permissions" name="wildcard-permissions">Wildcard Permissions</a></h2>
+<p>The above examples of permissions, “Open a file”, “View the ‘user/list’ web page”, etc are all valid permission statements. However, it would be very difficult computationally to interpret those natural language strings and determine if a user is allowed to perform that behavior or not.</p>
<p>So to enable easy-to-process yet still readable permission statements, Shiro provides powerful and intuitive permission syntax we refer to as the WildcardPermission.</p>
-
-<h3><a name="Permissions-SimpleUsage"></a>Simple Usage</h3>
-
-<p>Let's you want to protect access to your company's printers such that some people can print to particular printers, while others can query what jobs are currently in the queue. </p>
-
-<p>An extremely simple approach would be to use grant the user a "queryPrinter" permission. Then you could check to see if the user has the queryPrinter permission by calling:</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-subject.isPermitted(<span class="code-quote">"queryPrinter"</span>)
-</pre>
-</div></div>
-
+<a name="Permissions-SimpleUsage"></a>
+<h3><a href="#simple-usage" name="simple-usage">Simple Usage</a></h3>
+<p>Let’s you want to protect access to your company’s printers such that some people can print to particular printers, while others can query what jobs are currently in the queue.</p>
+<p>An extremely simple approach would be to use grant the user a “queryPrinter” permission. Then you could check to see if the user has the queryPrinter permission by calling:</p>
+<pre><code class="java">subject.isPermitted("queryPrinter")
+</code></pre>
<p>This is (mostly) equivalent to</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-subject.isPermitted( <span class="code-keyword">new</span> WildcardPermission(<span class="code-quote">"queryPrinter"</span>) )
-</pre>
-</div></div>
-
+<pre><code class="java">subject.isPermitted( new WildcardPermission("queryPrinter") )
+</code></pre>
<p>but more on that later.</p>
-
-<p>The simple permission string may work for simple applications, but it requires you to have permissions like "printPrinter", "queryPrinter", "managePrinter", etc. You can also grant a user "*" permissions using the wildcard character (giving this permission construct its name), which means they have <b><em>all</em></b> permissions across <em>the entire application</em>. </p>
-
-<p>But using this approach there's no way to just say a user has "all printer permissions". For this reason, Wildcard Permissions supports multiple <em>levels</em> of permissioning. </p>
-
-<h3><a name="Permissions-MultipleParts"></a>Multiple Parts</h3>
-
-<p>Wildcard Permissions support the concept of multiple <em>levels</em> or <em>parts</em>. For example, you could restructure the previous simple example by granting a user the permission </p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:query
-</pre>
-</div></div>
+<p>The simple permission string may work for simple applications, but it requires you to have permissions like “printPrinter”, “queryPrinter”, “managePrinter”, etc. You can also grant a user "*" permissions using the wildcard character (giving this permission construct its name), which means they have <strong><em>all</em></strong> permissions across <em>the entire application</em>.</p>
+<p>But using this approach there’s no way to just say a user has “all printer permissions”. For this reason, Wildcard Permissions supports multiple <em>levels</em> of permissioning.</p>
+<a name="Permissions-MultipleParts"></a>
+<h3><a href="#multiple-parts" name="multiple-parts">Multiple Parts</a></h3>
+<p>Wildcard Permissions support the concept of multiple <em>levels</em> or <em>parts</em>. For example, you could restructure the previous simple example by granting a user the permission</p>
+<pre><code class="ini">printer:query
+</code></pre>
<p>The colon in this example is a special character used to delimit the next part in the permission string.</p>
-
-<p>In this example, the first part is the domain that is being operated on (<tt>printer</tt>) and the second part is the action (<tt>query</tt>) being performed. The other above examples would be changed to:</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print
+<p>In this example, the first part is the domain that is being operated on (<code>printer</code>) and the second part is the action (<code>query</code>) being performed. The other above examples would be changed to:</p>
+<pre><code class="ini">printer:print
printer:manage
-</pre>
-</div></div>
-
+</code></pre>
<p>There is no limit to the number of parts that can be used, so it is up to your imagination in terms of ways that this could be used in your application.</p>
-
-<h4><a name="Permissions-MultipleValues"></a>Multiple Values</h4>
-
-<p>Each part can contain multiple values. So instead of granting the user both the "printer:print" and "printer:query" permissions, you could simply grant them one: </p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print,query
-</pre>
-</div></div>
-
-<p>which gives them the ability to <tt>print</tt> and <tt>query</tt> printers. And since they are granted both those actions, you could check to see if the user has the ability to query printers by calling:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-subject.isPermitted(<span class="code-quote">"printer:query"</span>)
-</pre>
-</div></div>
-<p>which would return <tt>true</tt></p>
-
-<h4><a name="Permissions-AllValues"></a>All Values</h4>
-
-<p>What if you wanted to grant a user <em>all</em> values in a particular part? It would be more convenient to do this than to have to manually list every value. Again, based on the wildcard character, we can do this. If the <tt>printer</tt> domain had 3 possible actions (<tt>query</tt>, <tt>print</tt>, and <tt>manage</tt>), this:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:query,print,manage
-</pre>
-</div></div>
+<a name="Permissions-MultipleValues"></a>
+<h4><a href="#multiple-values" name="multiple-values">Multiple Values</a></h4>
+<p>Each part can contain multiple values. So instead of granting the user both the “printer:print” and “printer:query” permissions, you could simply grant them one:</p>
+<pre><code class="ini">printer:print,query
+</code></pre>
+<p>which gives them the ability to <code>print</code> and <code>query</code> printers. And since they are granted both those actions, you could check to see if the user has the ability to query printers by calling:</p>
+<pre><code class="java">subject.isPermitted("printer:query")
+</code></pre>
+<p>which would return <code>true</code></p>
+<a name="Permissions-AllValues"></a>
+<h4><a href="#all-values" name="all-values">All Values</a></h4>
+<p>What if you wanted to grant a user <em>all</em> values in a particular part? It would be more convenient to do this than to have to manually list every value. Again, based on the wildcard character, we can do this. If the <code>printer</code> domain had 3 possible actions (<code>query</code>, <code>print</code>, and <code>manage</code>), this:</p>
+<pre><code class="ini">printer:query,print,manage
+</code></pre>
<p>simply becomes this:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:*
-</pre>
-</div></div>
-
-<p>Then, <em>any</em> permission check for "printer:XXX" will return <tt>true</tt>. Using the wildcard in this way scales better than explicitly listing actions since, if you added a new action to the application later, you don't need to update the permissions that use the wildcard character in that part.</p>
-
-<p>Finally, it is also possible to use the wildcard token in any part of a wildcard permission string. For example, if you wanted to grant a user the "view" action across <em>all</em> domains (not just printers), you could grant this:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-*:view
-</pre>
-</div></div>
-
-<p>Then any permission check for "foo:view" would return <tt>true</tt></p>
-
-<h3><a name="Permissions-InstanceLevelAccessControl"></a>Instance-Level Access Control</h3>
-
+<pre><code class="ini">printer:*
+</code></pre>
+<p>Then, <em>any</em> permission check for “printer:XXX” will return <code>true</code>. Using the wildcard in this way scales better than explicitly listing actions since, if you added a new action to the application later, you don’t need to update the permissions that use the wildcard character in that part.</p>
+<p>Finally, it is also possible to use the wildcard token in any part of a wildcard permission string. For example, if you wanted to grant a user the “view” action across <em>all</em> domains (not just printers), you could grant this:</p>
+<pre><code class="ini">*:view
+</code></pre>
+<p>Then any permission check for “foo:view” would return <code>true</code></p>
+<a name="Permissions-InstanceLevelAccessControl"></a>
+<h3>Instance-Level Access Control</h3>
<p>Another common usage of wildcard permissions is to model instance-level Access Control Lists. In this scenario you use three parts - the first is the <em>domain</em>, the second is the <em>action</em>(s), and the third is the instance(s) being acted upon.</p>
-
<p>So for example you could have</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:query:lp7200
+<pre><code class="ini">printer:query:lp7200
printer:print:epsoncolor
-</pre>
-</div></div>
-
-<p>The first defines the behavior to <tt>query</tt> the <tt>printer</tt> with the ID <tt>lp7200</tt>. The second permission defines the behavior to <tt>print</tt> to the <tt>printer</tt> with ID <tt>epsoncolor</tt>. If you grant these permissions to users, then they can perform specific behavior on <em>specific instances</em>. Then you can do a check in code:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-<span class="code-keyword">if</span> ( SecurityUtils.getSubject().isPermitted(<span class="code-quote">"printer:query:lp7200"</span>) {
- <span class="code-comment">// Return the current jobs on printer lp7200
-</span>}
-</pre>
-</div></div>
-
-<p>This is an extremely powerful way to express permissions. But again, having to define multiple instance IDs for all printers does not scale well, particularly when new printers are added to the system. You can instead use a wildcard:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print:*
-</pre>
-</div></div>
-
+</code></pre>
+<p>The first defines the behavior to <code>query</code> the <code>printer</code> with the ID <code>lp7200</code>. The second permission defines the behavior to <code>print</code> to the <code>printer</code> with ID <code>epsoncolor</code>. If you grant these permissions to users, then they can perform specific behavior on <em>specific instances</em>. Then you can do a check in code:</p>
+<pre><code class="java">if ( SecurityUtils.getSubject().isPermitted("printer:query:lp7200") {
+ // Return the current jobs on printer lp7200 }
+}
+</code></pre>
+<p>This is an extremely powerful way to express permissions. But again, having to define multiple instance IDs for all printers does not scale well, particularly when new printers are added to the system. You can instead use a wildcard:</p>
+<pre><code class="ini">printer:print:*
+</code></pre>
<p>This does scale, because it covers any new printers as well. You could even allow access to all actions on all printers:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:*:*
-</pre>
-</div></div>
-
+<pre><code class="ini">printer:*:*
+</code></pre>
<p>or all actions on a single printer:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:*:lp7200
-</pre>
-</div></div>
-
+<pre><code class="ini">printer:*:lp7200
+</code></pre>
<p>or even specific actions:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:query,print:lp7200
-</pre>
-</div></div>
-
-<p>The '*' wildcard and ',' sub-part separator can be used in any part of the permission.</p>
-
-<h4><a name="Permissions-MissingParts"></a>Missing Parts</h4>
-
+<pre><code class="ini">printer:query,print:lp7200
+</code></pre>
+<p>The ’*‘ wildcard and ’,’ sub-part separator can be used in any part of the permission.</p>
+<a name="Permissions-MissingParts"></a>
+<h4><a href="#missing-parts" name="missing-parts">Missing Parts</a></h4>
<p>One final thing to note about permission assignments: missing parts imply that the user has access to all values corresponding to that part. In other words,</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print
-</pre>
-</div></div>
-
+<pre><code class="ini">printer:print
+</code></pre>
<p>is equivalent to</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print:*
-</pre>
-</div></div>
-
+<pre><code class="ini">printer:print:*
+</code></pre>
<p>and</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer
-</pre>
-</div></div>
-
+<pre><code class="ini">printer
+</code></pre>
<p>is equivalent to</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:*:*
-</pre>
-</div></div>
-
+<pre><code class="ini">printer:*:*
+</code></pre>
<p>However, you can only leave off parts from the <em>end</em> of the string, so this:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:lp7200
-</pre>
-</div></div>
-
-<p>is <b><em>not</em></b> equivalent to</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:*:lp7200
-</pre>
-</div></div>
-
-<h2><a name="Permissions-CheckingPermissions"></a>Checking Permissions</h2>
-
-<p>While permission assignments use the wildcard construct quite a bit ("printer:print:*" = print to any printer) for convenience and scalability, permission <b>checks</b> at runtime should <em>always</em> be based on the most specific permission string possible.</p>
-
-<p>For example, if the user had a UI and they wanted to print a document to the <tt>lp7200</tt> printer, you <b>should</b> check if the user is permitted to do so by executing this code:<br clear="none">
-<font color=""></font></p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-<span class="code-keyword">if</span> ( SecurityUtils.getSubject().isPermitted(<span class="code-quote">"printer:print:lp7200"</span>) ) {
- <span class="code-comment">//print the document to the lp7200 printer
-</span>}
-</pre>
-</div></div>
-
-<p>That check is very specific and explicitly reflects what the user is attempting to do at that moment in time. </p>
-
-
+<pre><code class="ini">printer:lp7200
+</code></pre>
+<p>is <strong><em>not</em></strong> equivalent to</p>
+<pre><code class="ini">printer:*:lp7200
+</code></pre>
+<a name="Permissions-CheckingPermissions"></a>
+<h2><a href="#checking-permissions" name="checking-permissions">Checking Permissions</a></h2>
+<p>While permission assignments use the wildcard construct quite a bit (“printer:print:*” = print to any printer) for convenience and scalability, permission <strong>checks</strong> at runtime should <em>always</em> be based on the most specific permission string possible.</p>
+<p>For example, if the user had a UI and they wanted to print a document to the <code>lp7200</code> printer, you <strong>should</strong> check if the user is permitted to do so by executing this code:</p>
+<pre><code class="java">if ( SecurityUtils.getSubject().isPermitted("printer:print:lp7200") ) {
+ //print the document to the lp7200 printer }
+}
+</code></pre>
+<p>That check is very specific and explicitly reflects what the user is attempting to do at that moment in time.</p>
<p>The following however is much less ideal for a runtime check:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-<span class="code-keyword">if</span> ( SecurityUtils.getSubject().isPermitted(<span class="code-quote">"printer:print"</span>) ) {
- <span class="code-comment">//print the document
-</span>}
-</pre>
-</div></div>
-
-<p>Why? Because the second example says "You must be able to print to <b>any</b> printer for the following code block to execute". But remember that "printer:print" is equivalent to "printer:print:*"! </p>
-
-<p>Therefore, this is an incorrect check. What if the current user does not have the ability to print to any printer, but they <b>do</b> have the ability to print to say, the <tt>lp7200</tt> and <tt>epsoncolor</tt> printers. Then the 2nd example above would never allow them to print to the <tt>lp7200</tt> printer even though they have been granted that ability!</p>
-
-<p>So the rule of thumb is to use the most specific permission string possible when performing permission checks. Of course, the 2nd block above might be a valid check somewhere else in the application if you really did only want to execute the code block if the user was allowed to print to any printer (suspect, but possible). Your application will determine what checks make sense, but in general, the more specific, the better.</p>
-
-<h2><a name="Permissions-Implication%2CnotEquality"></a>Implication, not Equality</h2>
-
-<p>Why is it that runtime permission checks should be as specific as possible, but permission assignments can be a little more generic? It is because the permission checks are evaluated by <em>implication</em> logic - not equality checks.</p>
-
-<p>That is, if a user is assigned the <tt>user:*</tt> permission, this <em>implies</em> that the user can perform the <tt>user:view</tt> action. The string "user:*" is clearly not equal to "user:view", but the former implies the latter. "user:*" describes a superset of functionality of that defined by "user:view".</p>
-
-<p>To support implication rules, all permissions are translated in to object instances that implement the <tt>org.apache.shiro.authz.Permission</tt> interface. This is so that implication logic can be executed at runtime and that implication logic is often more complex than a simple string equality check. All of the wildcard behavior described in this document is actually made possible by the <tt>org.apache.shiro.authz.permission.WildcardPermission</tt> class implementation. Here are some more wildcard permission strings that show access by implication:</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-user:*
-</pre>
-</div></div>
+<pre><code class="java">if ( SecurityUtils.getSubject().isPermitted("printer:print") ) {
+ //print the document }
+}
+</code></pre>
+<p>Why? Because the second example says “You must be able to print to <strong>any</strong> printer for the following code block to execute”. But remember that “printer:print” is equivalent to “printer:print:*”!</p>
+<p>Therefore, this is an incorrect check. What if the current user does not have the ability to print to any printer, but they <strong>do</strong> have the ability to print to say, the <code>lp7200</code> and <code>epsoncolor</code> printers. Then the 2nd example above would never allow them to print to the <code>lp7200</code> printer even though they have been granted that ability!</p>
+<p>So the rule of thumb is to use the most specific permission string possible when performing permission checks. Of course, the 2nd block above might be a valid check somewhere else in the application if you really did only want to execute the code block if the user was allowed to print to any printer (suspect, but possible). Your application will determine what checks make sense, but in general, the more specific, the better.</p>
+<a name="Permissions-Implication%2CnotEquality"></a>
+<h2><a href="#implication-not-equality" name="implication-not-equality">Implication, not Equality</a></h2>
+<p>Why is it that runtime permission checks should be as specific as possible, but permission assignments can be a little more generic? It is because the permission checks are evaluated by <em>implication</em> logic - not equality checks.</p>
+<p>That is, if a user is assigned the <code>user:*</code> permission, this <em>implies</em> that the user can perform the <code>user:view</code> action. The string “user:*” is clearly not equal to “user:view”, but the former implies the latter. “user:*” describes a superset of functionality of that defined by “user:view”.</p>
+<p>To support implication rules, all permissions are translated in to object instances that implement the <code>org.apache.shiro.authz.Permission</code> interface. This is so that implication logic can be executed at runtime and that implication logic is often more complex than a simple string equality check. All of the wildcard behavior described in this document is actually made possible by the <code>org.apache.shiro.authz.permission.WildcardPermission</code> class implementation. Here are some more wildcard permission strings that show access by implication:</p>
+<pre><code class="ini">user:*
+</code></pre>
<p><em>implies</em> the ability to also delete a user:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-user:delete
-</pre>
-</div></div>
-
+<pre><code class="ini">user:delete
+</code></pre>
<p>Similarly,</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-user:*:12345
-</pre>
-</div></div>
+<pre><code class="ini">user:*:12345
+</code></pre>
<p><em>implies</em> the ability to also update user account with ID 12345:</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-user:update:12345
-</pre>
-</div></div>
-
+<pre><code class="ini">user:update:12345
+</code></pre>
<p>and</p>
-
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer
-</pre>
-</div></div>
+<pre><code class="ini">printer
+</code></pre>
<p><em>implies</em> the ability to print to any printer</p>
-<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
-<pre class="code-java">
-printer:print
-</pre>
-</div></div>
-
-<h2><a name="Permissions-PerformanceConsiderations"></a>Performance Considerations</h2>
-
-<p>Permission checks are more complex than a simple equals comparison, so runtime implication logic must execute for each assigned Permission. When using permission strings like the ones shown above, you're implicitly using Shiro's default <tt>WildcardPermission</tt> which executes the necessary implication logic.</p>
-
-<p>Shiro's default behavior for Realm implementations is that, for every permission check (for example, a call to <tt>subject.isPermitted</tt> ), <em>all</em> of the permissions assigned to that user (in their Groups, Roles, or directly assigned to them) need to be checked individually for implication. Shiro 'short circuits' this process by returning immediately after the first successful check occurs to increase performance, but it is not a silver bullet.</p>
-
-<p>This is usually extremely fast when users, roles and permissions are cached in memory when using a proper <a href="cachemanager.html" title="CacheManager">CacheManager</a>, which Shiro does support for Realm implementations. Just know that with this default behavior, as the number of permissions assigned to a user or their roles or groups increase, the time to perform the check will necessarily increase.</p>
-
-<p>If a Realm implementor has a more efficient way of checking permissions and performing this implication logic, especially if based on the applicaton's data model, they should implement that as part of their Realm isPermitted* method implementations. The default Realm/WildcardPermission support exists to cover 80-90% of most use cases, but it might not be the best solution for applications that have massive amounts of permissions to store and/or check at runtime.</p>
-
-<h2><a name="Permissions-Lendahandwithdocumentation"></a>Lend a hand with documentation </h2>
-
-<p>While we hope this documentation helps you with the work you're doing with Apache Shiro, the community is improving and expanding the documentation all the time. If you'd like to help the Shiro project, please consider corrected, expanding, or adding documentation where you see a need. Every little bit of help you provide expands the community and in turn improves Shiro. </p>
-
-<p>The easiest way to contribute your documentation is to send it to the <a class="external-link" href="http://shiro-user.582556.n2.nabble.com/" rel="nofollow">User Forum</a> or the <a href="mailing-lists.html" title="Mailing Lists">User Mailing List</a>.</p>
-
+<pre><code class="ini">printer:print
+</code></pre>
+<a name="Permissions-PerformanceConsiderations"></a>
+<h2><a href="#performance-considerations" name="performance-considerations">Performance Considerations</a></h2>
+<p>Permission checks are more complex than a simple equals comparison, so runtime implication logic must execute for each assigned Permission. When using permission strings like the ones shown above, you’re implicitly using Shiro’s default <code>WildcardPermission</code> which executes the necessary implication logic.</p>
+<p>Shiro’s default behavior for Realm implementations is that, for every permission check (for example, a call to <code>subject.isPermitted</code>), <em>all</em> of the permissions assigned to that user (in their Groups, Roles, or directly assigned to them) need to be checked individually for implication. Shiro ‘short circuits’ this process by returning immediately after the first successful check occurs to increase performance, but it is not a silver bullet.</p>
+<p>This is usually extremely fast when users, roles and permissions are cached in memory when using a proper <a href="cachemanager.html" title="CacheManager">CacheManager</a>, which Shiro does support for Realm implementations. Just know that with this default behavior, as the number of permissions assigned to a user or their roles or groups increase, the time to perform the check will necessarily increase.</p>
+<p>If a Realm implementor has a more efficient way of checking permissions and performing this implication logic, especially if based on the applicaton’s data model, they should implement that as part of their Realm isPermitted* method implementations. The default Realm/WildcardPermission support exists to cover 80-90% of most use cases, but it might not be the best solution for applications that have massive amounts of permissions to store and/or check at runtime.</p>
+<a name="Permissions-Lendahandwithdocumentation"></a>
+<h2><a href="#lend-a-hand-with-documentation" name="lend-a-hand-with-documentation">Lend a hand with documentation</a></h2>
+<p>While we hope this documentation helps you with the work you’re doing with Apache Shiro, the community is improving and expanding the documentation all the time. If you’d like to help the Shiro project, please consider corrected, expanding, or adding documentation where you see a need. Every little bit of help you provide expands the community and in turn improves Shiro.</p>
+<p>The easiest way to contribute your documentation is to send it to the <a href="http://shiro-user.582556.n2.nabble.com/">User Forum</a> or the <a href="mailing-lists.html" title="Mailing Lists">User Mailing List</a>.</p>
</div>
Modified: shiro/site/publish/powered-by-shiro.html
URL: http://svn.apache.org/viewvc/shiro/site/publish/powered-by-shiro.html?rev=1766414&r1=1766413&r2=1766414&view=diff
==============================================================================
--- shiro/site/publish/powered-by-shiro.html (original)
+++ shiro/site/publish/powered-by-shiro.html Mon Oct 24 14:33:52 2016
@@ -78,33 +78,34 @@
<div id="content">
- <h1><a name="PoweredbyShiro-OrganizationsusingApacheShiro"></a>Organizations using Apache Shiro</h1>
-
-<p>Please consider adding yourself to the Apache Shiro PoweredBy page. By letting others know that you are using Shiro, you help expand the community and in turn improve Shiro. Win/Win!</p>
-
-<h3><a name="PoweredbyShiro-Stormpath"></a><a class="external-link" href="https://stormpath.com/" rel="nofollow">Stormpath</a></h3>
-<p>Stormpath builds software products that make application security easy for developers and their organization. Les Hazlewood, the Apache Shiro PMC Chair, is Stormpath's founder and CTO.</p>
-<ul><li>Stormpath uses Shiro as the core security subsystem for their products.</li><li>Shiro is used to support Stormpath's Single Sign-On (SSO) architecture.</li><li>Shiro's pluggable Realm architecture is used by Stormpath's runtime plugin system to allow changing an application's Realms at runtime, without requiring a server restart.</li></ul>
-
-<h3><a name="PoweredbyShiro-LargeFinancialInformationProvider"></a>Large Financial Information Provider</h3>
+ <a name="PoweredbyShiro-OrganizationsusingApacheShiro"></a>
+<h1><a href="#organizations-using-apache-shiro" name="organizations-using-apache-shiro">Organizations using Apache Shiro</a></h1>
+<p>Please consider adding yourself to the Apache Shiro PoweredBy page. By letting others know that you are using Shiro, you help expand the community and in turn improve Shiro. Win/Win!</p>
+<a name="PoweredbyShiro-Stormpath"></a>
+<h3><a href="https://stormpath.com/">Stormpath</a></h3>
+<p>Stormpath builds software products that make application security easy for developers and their organization. Les Hazlewood, the Apache Shiro PMC Chair, is Stormpath’s founder and CTO.</p>
+<ul>
+ <li>Stormpath uses Shiro as the core security subsystem for their products.</li>
+ <li>Shiro is used to support Stormpath’s Single Sign-On (SSO) architecture.</li>
+ <li>Shiro’s pluggable Realm architecture is used by Stormpath’s runtime plugin system to allow changing an application’s Realms at runtime, without requiring a server restart.</li>
+</ul>
+<a name="PoweredbyShiro-LargeFinancialInformationProvider"></a>
+<h3><a href="#large-financial-information-provider" name="large-financial-information-provider">Large Financial Information Provider</a></h3>
<p>Using Shiro in a large scale external web application for authentication, authorization, and custom Session clustering in an enterprise clustered cache</p>
-
-<h3><a name="PoweredbyShiro-MuleSoft"></a><a class="external-link" href="http://mulesoft.com" rel="nofollow">MuleSoft</a></h3>
-<p>The company behind <a class="external-link" href="http://mulesoft.org" rel="nofollow">Mule</a>, MuleSoft is behind the leading open source middleware, making integration and managing applications easier for everyone.</p>
-
-<p>Mule uses Shiro to provide authentication and authorization to hosted services and resources. This allows users to secure HTTP/REST services, Web Services, message queues, data and file access with the simplicity of Shiro.</p>
-
-<h3><a name="PoweredbyShiro-Sonatype"></a><a class="external-link" href="http://www.sonatype.com" rel="nofollow">Sonatype</a></h3>
+<a name="PoweredbyShiro-MuleSoft"></a>
+<h3><a href="http://mulesoft.com">MuleSoft</a></h3>
+<p>The company behind <a href="http://mulesoft.org">Mule</a>, MuleSoft is behind the leading open source middleware, making integration and managing applications easier for everyone.</p>
+<p>Mule uses Shiro to provide authentication and authorization to hosted services and resources. This allows users to secure HTTP/REST services, Web Services, message queues, data and file access with the simplicity of Shiro.</p>
+<a name="PoweredbyShiro-Sonatype"></a>
+<h3><a href="http://www.sonatype.com">Sonatype</a></h3>
<p>The company behind <a class="external-link" href="http://maven.apache.org">Maven</a>, Sonatype streamlines infrastructure and development workflows for Maven-centric development environments.</p>
-<ul><li>Sonatype uses Shiro to secure <a class="external-link" href="http://www.sonatype.com/nexus-professional.html" rel="nofollow">Nexus</a>, the leading open-source and professional Maven repository manager.</li></ul>
-
-
-
+<ul>
+ <li>Sonatype uses Shiro to secure <a href="http://www.sonatype.com/nexus-professional.html">Nexus</a>, the leading open-source and professional Maven repository manager.</li>
+</ul>
<h2><a name="PoweredbyShiro-Template"></a>Template</h2>
<p><a class="external-link" href="http://www.apache.org">Your Company Name</a> - Your company description</p>
<ul><li>Any details you can share</li><li>...</li></ul>
-
</div>
</div><!--END WRAPPER-->
Modified: shiro/site/publish/privacy-policy.html
URL: http://svn.apache.org/viewvc/shiro/site/publish/privacy-policy.html?rev=1766414&r1=1766413&r2=1766414&view=diff
==============================================================================
--- shiro/site/publish/privacy-policy.html (original)
+++ shiro/site/publish/privacy-policy.html Mon Oct 24 14:33:52 2016
@@ -78,16 +78,18 @@
<div id="content">
- <h1><a name="PrivacyPolicy-ApacheShiroPrivacyPolicy"></a>Apache Shiro Privacy Policy</h1>
-
+ <a name="PrivacyPolicy-ApacheShiroPrivacyPolicy"></a>
+<h1><a href="#apache-shiro-privacy-policy" name="apache-shiro-privacy-policy">Apache Shiro Privacy Policy</a></h1>
<p>Information about your use of this website is collected using server access logs and a tracking cookie. The collected information consists of the following:</p>
-<ol><li>The IP address from which you access the website;</li><li>The type of browser and operating system you use to access our site;</li><li>The date and time you access our site;</li><li>The pages you visit; and</li><li>The addresses of pages from where you followed a link to our site.</li></ol>
-
-
+<ul>
+ <li>The IP address from which you access the website;</li>
+ <li>The type of browser and operating system you use to access our site;</li>
+ <li>The date and time you access our site;</li>
+ <li>The pages you visit; and</li>
+ <li>The addresses of pages from where you followed a link to our site.</li>
+</ul>
<p>Part of this information is gathered using a tracking cookie set by the Google Analytics service and handled by Google as described in their privacy policy. See your browser documentation for instructions on how to disable the cookie if you prefer not to share this data with Google.</p>
-
<p>We use the gathered information to help us make our site more useful to visitors and to better understand how and when our site is used. We do not track or collect personally identifiable information or associate gathered data with any personally identifying information from other sources.</p>
-
<p>By using this website, you consent to the collection of this data in the manner and for the purpose described above.</p>
</div>