You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@shiro.apache.org by bm...@apache.org on 2021/10/11 07:17:03 UTC
[shiro-site] branch jbake updated: convert and delete some more
pages.
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 3bd0e3f convert and delete some more pages.
new d479053 Merge pull request #116 from bmarwell/jbake
3bd0e3f is described below
commit 3bd0e3f962bc868397c3b9253fc8a3d8f22c7b07
Author: Benjamin Marwell <bm...@apache.org>
AuthorDate: Sun Oct 10 22:44:02 2021 +0200
convert and delete some more pages.
---
authorization-features.md | 24 ----
documentation-help-block.md | 7 -
java-cryptography-guide.md.vtl | 105 ---------------
jbake/content/authorization-features.adoc | 55 ++++++++
jbake/content/java-cryptography-guide.adoc | 89 +++++++++++++
jbake/content/roadmap.adoc | 44 ++++++
version-2-brainstorming.md | 206 -----------------------------
wiki-todos.md | 13 --
8 files changed, 188 insertions(+), 355 deletions(-)
diff --git a/authorization-features.md b/authorization-features.md
deleted file mode 100644
index 99eac94..0000000
--- a/authorization-features.md
+++ /dev/null
@@ -1,24 +0,0 @@
-title: Apache Shiro Authorization Features
-
-# Apache Shiro Authorization Features
-
-Authorization, also called access control, is the process of determining access rights to resources in an application. In other words, determining "who has access to what." Authorization is used to answer security questions like, "is the user allowed to edit accounts", "is this user allowed to view this web page", "does this user have access to this button?" These are all decisions determining what a user has access to and therefore all represent authorization checks.
-
-Authorization is a critical element of any application but it can quickly become very complex. Shiro's goal is to eliminate much of the complexity around authorization so that you can more easily build secure software. Below is a highlight of the Shiro authorization features.
-
-## Features
-
-* **Subject-based** - Almost everything you do in Shiro is based on the currently executing user, called a Subject. And you can easily access the subject retrieve the Subject and checks its roles, permissions, or other relevant attributes anywhere in your code. This makes it easier for you to understand and work with Shiro in your applications.
-
-* **Checks based on roles or permissions** - Since the complexity of authorization differs greatly between applications, Shiro is designed to be flexible, supporting both role-based security and permission-based security based on your projects needs.
-
-* **Powerful and intuitive permission syntax** - As an option, Shiro provides an out-of-the-box permission syntax, called Wildcard Permissions, that help you model the fine grained access policies your application may have. By using Shiro's Wildcard Permissions you get an easy-to-process and human readable syntax. Moreoever, you don't have to go through the time-consuming effort and complexity of creating your own method for representing your access policies.
-
-* **Multiple enforcement options** - Authorization checks in Shiro can be done through in-code checks, JDK 1.5 annotations, AOP, and JSP/GSP Taglibs. Shiro's goal is to give you the choice to use the option you think are best based on your preferences and project needs.
-
-* **Strong caching support** - Any of the modern open-source and/or enterprise caching products can be plugged in to Shiro to provide a fast and efficient user-experience. For authorization, caching is crucial for performance in larger environments or with more complex policies using back-end security data sources.
-
-* **Pluggable data sources** - Shiro uses pluggable data access objects, referred to as Realms, to connect to security data sources where you keep your access control information, like an LDAP server or a relational database. To help you avoid building and maintaining integrations yourself, Shiro provides out-of-the-box realms for popular data sources like LDAP, Active Directory, and JDBC. If needed, you can also create your own realms to support specific functionality not included i [...]
-
-* **Supports any data model** - Shiro can support any data model for access control—it doesn't force a model on you. Your realm implementation ultimately decides how your permissions and roles are grouped together and whether to return a "yes" or a "no" answer to Shiro. This feature allows you to architect your application in the manner you chose and Shiro will bend to support you.
-<input type="hidden" id="ghEditPage" value="authorization-features.md"></input>
diff --git a/documentation-help-block.md b/documentation-help-block.md
deleted file mode 100644
index ebff287..0000000
--- a/documentation-help-block.md
+++ /dev/null
@@ -1,7 +0,0 @@
-<a name="DocumentationHelpBlock-Lendahandwithdocumentation"></a>
-##Lend a hand with documentation
-
-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 correcting, expanding, or adding documentation where you see a need. Every little bit of help you provide expands the community and in turn improves Shiro.
-
-The easiest way to contribute your documentation is to send it to the [User Forum](http://shiro-user.582556.n2.nabble.com/) or the [User Mailing List](mailing-lists.html "Mailing Lists").
-<input type="hidden" id="ghEditPage" value="documentation-help-block.md"></input>
diff --git a/java-cryptography-guide.md.vtl b/java-cryptography-guide.md.vtl
deleted file mode 100644
index e59cd7b..0000000
--- a/java-cryptography-guide.md.vtl
+++ /dev/null
@@ -1,105 +0,0 @@
-<a name="JavaCryptographyGuide-JavaCryptographyGuidewithApacheShiro"></a>
-Java Cryptography Guide with Apache Shiro
-=========================================
-
-<div class="addthis_toolbox addthis_default_style">
-<a class="addthis_button_compact" href="http://www.addthis.com/bookmark.php?v=250&pubid=ra-4d66ef016022c3bd">Share</a>
-<span class="addthis_separator">|</span>
-<a class="addthis_button_preferred_1"></a>
-<a class="addthis_button_preferred_2"></a>
-<a class="addthis_button_preferred_3"></a>
-<a class="addthis_button_preferred_4"></a>
-</div>
-<script type="text/javascript">var addthis_config = {"data_track_clickback":true};</script>
-<script type="text/javascript" src="http://s7.addthis.com/js/250/addthis_widget.js#pubid=ra-4d66ef016022c3bd"></script>
-
-
-Cryptography is the protecting of information from undesired access by hiding it or converting it into nonsense so that no one can read it.
-
-Shiro is a major part of Shiro because we wanted to provide you with simplicity on what is typically a very complex topic. For example, the Java Cryptography Extension (JCE) already handles cryptography in a Java environment but is very difficult to learn and use. So we grabbed the concepts made available by the JCE API and make them available to us mortals. In addition, all of the calls in the JCE are procedural which doesn't fit in Java's Object Oriented paradigm. So in Shiro, our cryp [...]
-
-<a name="JavaCryptographyGuide-ElementsofCryptography"></a>
-Elements of Cryptography
-------------------------
-
-cryptography has two core elements in Shiro-- ciphers and hashes.
-
-<a name="JavaCryptographyGuide-CiphersDefined"></a>
-#[[###Ciphers Defined]]#
-
-Ciphers are algorightms that can either encrypt or decrypt based on public or private key pair. And there are two different types of ciphers:
-
-* Symmetric Cipher - encrypts and decrypts using the same key.
-
-* Asymmetric Cipher - uses different keys for encryption and decryption.
-
-Both cipher type are support in Shiro.
-
-<a name="JavaCryptographyGuide-HashesDefined"></a>
-#[[###Hashes Defined]]#
-
-A hash is a one-way irreversible conversion of an input source. In the JDK, a hash is referred to as a message digest. A cryptographic hash and a message digests are the same thing and both terms or correct.
-
-<a name="JavaCryptographyGuide-CommonusesforHashes"></a>
-#[[####Common uses for Hashes]]#
-
-Hashes are often used to transforms credentials like passwords or biometric data. It's a one way transformation so you can never see what the original value was. This is a very safe way of storing passwords so that no one other than the user will ever know a password, even if your system is compromised.
-
-In addition, Shiro's hashes can be used with any type of data with an underlying byte array. Examples of this data include files, streams, byte arrays, strings, and character arrays.
-
-<a name="JavaCryptographyGuide-CipherFeatures"></a>
-Cipher Features
----------------
-
-<a name="JavaCryptographyGuide-Shiro%27sCipherServiceInterface"></a>
-#[[###Shiro's CipherService Interface]]#
-
-``` java
-public interface CipherService {
-
- ByteSource encrypt( byte[] raw, byte[] key);
-
- void encrypt(InputStream in, OutputStream out, byte[] key);
-
- ByteSource decrypt( byte[] cipherText, byte[] key);
-
- void decrypt(InputStream in, OutputStream out, byte[] key);
-}
-```
-
-<a name="JavaCryptographyGuide-HashFeatures"></a>
-Hash Features
--------------
-
-#tip('Tip', 'Salts are important when hashing ...')
-
-#tip('Tip', 'Repeated hashes are important when hashing ...')
-
-<a name="JavaCryptographyGuide-Shiro%27sHashInterface"></a>
-#[[###Shiro's Hash Interface]]#
-
-``` java
-public interface Hash {
- byte[] getBytes();
- String toHex();
- String toBase64();
-}
-```
-
-<a name="JavaCryptographyGuide-ExamplesofhowtouseHashesinyourcode"></a>
-#[[###Examples of how to use Hashes in your code]]#
-
-``` java
-//some examples:
-new Md5Hash(“foo”).toHex();
-
-//File MD5 Hash value for checksum:
-new MD5Hash( aFile ).toHex();
-
-//store a password, but not raw:
-new Sha256(aPassword, salt, 1024).toBase64();
-```
-
-#lendAHandDoc()
-
-<input type="hidden" id="ghEditPage" value="java-cryptography-guide.md.vtl"></input>
diff --git a/jbake/content/authorization-features.adoc b/jbake/content/authorization-features.adoc
new file mode 100644
index 0000000..72ab22b
--- /dev/null
+++ b/jbake/content/authorization-features.adoc
@@ -0,0 +1,55 @@
+= Authorization Features
+:jbake-type: page
+:jbake-status: published
+:jbake-tags: documentation, authorization, features
+:idprefix:
+:icons: font
+
+Authorization, also called access control, is the process of determining access rights to resources in an application.
+In other words, determining *"who has access to what"*.
+Authorization is used to answer security questions like, "is the user allowed to edit accounts", "is this user allowed to view this web page", "does this user have access to this button"?
+These are all decisions determining what a user has access to and therefore all represent authorization checks.
+
+Authorization is a critical element of any application but it can quickly become very complex.
+Shiro's goal is to eliminate much of the complexity around authorization so that you can more easily build secure software.
+Below is a highlight of the Shiro authorization features.
+
+== Features
+
+* *Subject-based*
++
+Almost everything you do in Shiro is based on the currently executing user, called a Subject.
+And you can easily access the subject retrieve the Subject and checks its roles, permissions, or other relevant attributes anywhere in your code.
+This makes it easier for you to understand and work with Shiro in your applications.
+
+* *Checks based on roles or permissions*
++
+Since the complexity of authorization differs greatly between applications, Shiro is designed to be flexible, supporting both role-based security and permission-based security based on your projects needs.
+
+* *Powerful and intuitive permission syntax*
++
+As an option, Shiro provides an out-of-the-box permission syntax, called Wildcard Permissions, that help you model the fine grained access policies your application may have.
+By using Shiro's Wildcard Permissions you get an easy-to-process and human readable syntax.
+Moreoever, you don't have to go through the time-consuming effort and complexity of creating your own method for representing your access policies.
+
+* *Multiple enforcement options*
++
+Authorization checks in Shiro can be done through in-code checks, JDK 1.5 annotations, AOP, and JSP/GSP Taglibs.
+Shiro's goal is to give you the choice to use the option you think are best based on your preferences and project needs.
+
+* *Strong caching support*
++
+Any of the modern open-source and/or enterprise caching products can be plugged in to Shiro to provide a fast and efficient user-experience.
+For authorization, caching is crucial for performance in larger environments or with more complex policies using back-end security data sources.
+
+* *Pluggable data sources*
++
+Shiro uses pluggable data access objects, referred to as Realms, to connect to security data sources where you keep your access control information, like an LDAP server or a relational database.
+To help you avoid building and maintaining integrations yourself, Shiro provides out-of-the-box realms for popular data sources like LDAP, Active Directory, and JDBC.
+If needed, you can also create your own realms to support specific functionality not included in the basic realms.
+
+* *Supports any data model*
++
+Shiro can support any data model for access control — it doesn't force a model on you.
+Your realm implementation ultimately decides how your permissions and roles are grouped together and whether to return a "yes" or a "no" answer to Shiro.
+This feature allows you to architect your application in the manner you chose and Shiro will bend to support you.
diff --git a/jbake/content/java-cryptography-guide.adoc b/jbake/content/java-cryptography-guide.adoc
new file mode 100644
index 0000000..b0f505b
--- /dev/null
+++ b/jbake/content/java-cryptography-guide.adoc
@@ -0,0 +1,89 @@
+= Java Cryptography Guide
+:jbake-type: page
+:jbake-status: published
+:jbake-tags: documentation, cryptography
+:idprefix:
+:icons: font
+:toc:
+
+Cryptography is the protecting of information from undesired access by hiding it or converting it into nonsense so that no one can read it.
+
+Shiro is a major part of Shiro because we wanted to provide you with simplicity on what is typically a very complex topic.
+For example, the Java Cryptography Extension (JCE) already handles cryptography in a Java environment but is very difficult to learn and use.
+So we grabbed the concepts made available by the JCE API and make them available to us mortals.
+In addition, all of the calls in the JCE are procedural which doesn't fit in Java's Object Oriented paradigm.
+So in Shiro, our cryptography features are all object oriented.
+
+== Elements of Cryptography
+
+cryptography has two core elements in Shiro– ciphers and hashes.
+
+=== Ciphers Defined
+
+Ciphers are algorightms that can either encrypt or decrypt based on public or private key pair. And there are two different types of ciphers:
+
+* Symmetric Cipher - encrypts and decrypts using the same key.
+
+* Asymmetric Cipher - uses different keys for encryption and decryption.
+
+Both cipher type are support in Shiro.
+
+=== Hashes Defined
+
+A hash is a one-way irreversible conversion of an input source. In the JDK, a hash is referred to as a message digest. A cryptographic hash and a message digests are the same thing and both terms or correct.
+
+==== Common uses for Hashes
+
+Hashes are often used to transforms credentials like passwords or biometric data. It's a one way transformation so you can never see what the original value was. This is a very safe way of storing passwords so that no one other than the user will ever know a password, even if your system is compromised.
+
+In addition, Shiro's hashes can be used with any type of data with an underlying byte array. Examples of this data include files, streams, byte arrays, strings, and character arrays.
+
+== Cipher Features
+
+=== Shiro's CipherService Interface
+
+[source,java]
+----
+public interface CipherService {
+
+ ByteSource encrypt( byte[] raw, byte[] key);
+
+ void encrypt(InputStream in, OutputStream out, byte[] key);
+
+ ByteSource decrypt( byte[] cipherText, byte[] key);
+
+ void decrypt(InputStream in, OutputStream out, byte[] key);
+}
+
+----
+
+== Hash Features
+
+TIP: Salts are important when hashing…
+
+TIP: Repeated hashes are important when hashing …
+
+=== Shiro's Hash Interface
+
+[source,java]
+----
+public interface Hash {
+ byte[] getBytes();
+ String toHex();
+ String toBase64();
+}
+----
+
+=== Examples of how to use Hashes in your code
+
+[source,java]
+----
+//some examples:
+new Md5Hash("foo").toHex();
+
+//File MD5 Hash value for checksum:
+new MD5Hash( aFile ).toHex();
+
+//store a password, but not raw:
+new Sha256(aPassword, salt, 1024).toBase64();
+----
diff --git a/jbake/content/roadmap.adoc b/jbake/content/roadmap.adoc
new file mode 100644
index 0000000..b093925
--- /dev/null
+++ b/jbake/content/roadmap.adoc
@@ -0,0 +1,44 @@
+= Roadmap
+:jbake-type: page
+:jbake-status: published
+:jbake-tags: events, meetings
+:idprefix:
+:icons: font
+:toc:
+
+We currently do not have a timeline for version 2, but we are already collecting ideas.
+New features are implemented into the "main" branch every now and then.
+
+You can find the complete list of ideas in our wiki: link:https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming[Version 2 Brainstorming].
+
+[IMPORTANT]
+====
+This list is not exhausive.
+The wiki page should be regarded as the primary source.
+Feel free to tell us about your ideas on the link:mailing-lists.html[mailing lists]!
+====
+
+== Excerpt of Version 2 features
+
+* Event support
+
+* Authorization ANTLR Grammar
+
+* Multi-Stage Authentication via request/response
++
+In applications that need to authenticate via multiple mechanisms (e.g. multi-factor authentication), a Request/Response protocol for login would probably be easier to use to support such workflows.
+
+* Captcha Support
+
+== Excerpt of Version 2 changes
+
+
+* Rename AuthenticationInfo to Account
+
+* Realm refactoring
+
+* New layout of maven modules
+
+* Redefine Component Names
++
+Change classes named FooDAO to FooStore instead.
diff --git a/version-2-brainstorming.md b/version-2-brainstorming.md
deleted file mode 100644
index 6a24c41..0000000
--- a/version-2-brainstorming.md
+++ /dev/null
@@ -1,206 +0,0 @@
-
-* [Rename AuthenticationInfo to Account](#Version2Brainstorming-RenameAuthenticationInfotoAccount)
-* [Realm refactoring](#Version2Brainstorming-Realmrefactoring)
-* [Split shiro-core into modules](#Version2Brainstorming-Splitshirocoreintomodules)
-* [Event-driven design](#Version2Brainstorming-Eventdrivendesign)
-* [Subject PrincipalCollection](#Version2Brainstorming-SubjectPrincipalCollection)
-* [Component Names](#Version2Brainstorming-ComponentNames)
-* [Authorization ANTLR Grammar](#Version2Brainstorming-AuthorizationANTLRGrammar)
-* [AuthorizationRequest/Response](#Version2Brainstorming-AuthorizationRequest%2FResponse)
-* [Reinforce customization via OO Delegation (composition over inheritance)](#Version2Brainstorming-ReinforcecustomizationviaOODelegation%28compositionoverinheritance%29)
-* [Multi-Stage Authentication via request/response](#Version2Brainstorming-MultiStageAuthenticationviarequest%2Fresponse)
-* [Captcha Support](#Version2Brainstorming-CaptchaSupport)
-* [Configuration per filter instance and no path matching](#Version2Brainstorming-Configurationperfilterinstanceandnopathmatching)
-* [Web module repackaging.](#Version2Brainstorming-Webmodulerepackaging.)
-
-There is currently no timeline for a version 2, but this space represents any brainstorming efforts that the community wishes to address that may be major feature enhancements that can't be backwards compatible. Typically discussions from the dev list resulting in some form of consensus will probably make it into this page. Actionable items will go into Jira, potentially referencing this page for clarity.
-
-* (I know this isn't a feature but its equally is not more important) Deeper and more accessible documentation and how-tos.
-* management system for long lived hashes
-* token/ticket system
-* more generalized way to handle unauthorized exceptions
-* lower level crypto toolkit to facilitate customizations
-* unauthorizedUrl per path filter
-
-<a name="Version2Brainstorming-RenameAuthenticationInfotoAccount"></a>
-###Rename AuthenticationInfo to Account
-
-The existing `AuthenticationInfo` name is less intuitive and is essentially the same thing.
-
-<a name="Version2Brainstorming-Realmrefactoring"></a>
-###Realm refactoring
-
-Most Realms differ little in their implementations - mostly by the protocols they use. Create a 'DefaultRealm' implementation (or something similar) that allows pluggable AccountResolver and AuthorizationResolver interfaces that abstract away interaction with the data stores and the rest of the internal Realm logic (e.g. authc and authz caching, etc) can be shared by most Realm implementation.
-
-<a name="Version2Brainstorming-Splitshirocoreintomodules"></a>
-###Split shiro-core into modules
-
-Maybe shiro-core should be split up into separate modules (e.g. shiro-crypto, shiro-authc, shiro-authz, etc) if possible. This may or may not be possible due to the tight integration of APIs (e.g. Shiro authentication depends on shiro hashing (crypto) etc). A cursory investigation should be made if possible.
-
-<a name="Version2Brainstorming-Eventdrivendesign"></a>
-###Event-driven design
-
-**This can be in 1.3+ as these would be all new packages/classes and do not require signature changes to existing code**
-
-Utilize events significantly and more effectively. Base on Akka's event model and [Guava's EventBus](http://code.google.com/p/guava-libraries/wiki/EventBusExplained). This enables ideal loose coupling/high cohesion plugins/integration/customization.
-
-Package: `org.apache.shiro.event`
-
-Potential classes:
-
-``` java
-public class ShiroEvent extends EventObject {
-
- private final long timestamp; //millis since Epoch (UTC time zone).
- public ShiroEvent(Object source) {
- super(source);
- this.timestamp = new Date().getTime();
- }
-
- public long getTimestamp() {
- return timestamp;
- }
-}
-```
-
-``` java
-
-public interface Publisher {
-
- void publish(Object event);
-}
-```
-
-``` java
-/** Marker annotation for a method that wishes to receive a particular event instance. */
-public @interface Subscribe {
-}
-```
-
-``` java
-/**
- * Listener implementations just annotate a method as @Subscribe.
- * The single method argument determines the type of event received.
- */
-public class MyListener {
-
- @Subscribe
- public void doSomething(SomeEvent event) {
- ...
- }
-}
-```
-
-``` java
-public interface SubscriberRegistry {
-
- void register(Object subscriber);
-
- void unregister(Object subscriber);
-}
-```
-
-An EventBus can be created based on Publisher + SubscriberRegistry:
-
-``` java
-public class SynchronousEventBus implements Publisher, SubscriberRegistry {
- ...
-}
-```
-
-<a name="Version2Brainstorming-SubjectPrincipalCollection"></a>
-###Subject PrincipalCollection
-
-Convert this to be a sub-interface of Map with additional per-Realm utility methods.
-
-See the [PrincipalMap](https://github.com/apache/shiro/blob/main/core/src/main/java/org/apache/shiro/subject/PrincipalMap.java) concept for ideas (experimental, not referenced in Shiro 1.x at the moment).
-
-Maybe rename this to 'attributes'? i.e. `subject.getAttributes()`?
-
-<a name="Version2Brainstorming-ComponentNames"></a>
-###Component Names
-
-Change classes named FooDAO to FooStore instead.
-
-<a name="Version2Brainstorming-AuthorizationANTLRGrammar"></a>
-###Authorization ANTLR Grammar
-
-Ideally, we can have a single annotation:
-
-``` java
-@Secured("authz expression here")
-public void someMethod(){...}
-```
-
-Where the 'authz expression here' is authorization assertion statement backed by an ANTLR lexer/parser, for example:
-
-``` java
-@Secured("(role(admin) || role(developer)) || perm(account:12345:open)")
-```
-
-This would translate the expression into the relevant hasRole/isPermitted calls.
-
-<a name="Version2Brainstorming-AuthorizationRequest%2FResponse"></a>
-###AuthorizationRequest/Response
-
-Employing the same grammar as mentioned above, instead of multiple subject.isPermitted/hasRole calls, the same thing could be achieved with an AuthorizationRequest/Response scheme. For example:
-
-``` java
-AuthorizationRequest request = //create request w/ expression
-AuthorizationResponse response = subject.authorize(authorizationRequest);
-if (response.isAuthorized()) {
-...
-} else {
-...
-}
-```
-
-<a name="Version2Brainstorming-ReinforcecustomizationviaOODelegation%28compositionoverinheritance%29"></a>
-###Reinforce customization via OO Delegation (composition over inheritance)
-
-* Any of the features provided by PathMatchingFilter would be provided for any configured filter via a proxy mechanism. The proxy would likely support the PathMatchingFilter features, setting request attributes as necessary for the wrapped filter to react to. This eliminates the need to subclass PathMatchingFilter to utilize these features.
-* The same principal would be probably be applied for realms. A DefaultRealm could be created that delegates to an AuthenticationInfoAccessor and AuthorizationInfoAccessor (or whatever we want to call them) that performs the same behavior as AuthenticatingRealm#doGetAuthenticationInfo and AuthorizingRealm#doGetAuthorizationInfo. The end result is no more subclassing realms for 95% of use cases, and instead providing accessors.
-
-<a name="Version2Brainstorming-MultiStageAuthenticationviarequest%2Fresponse"></a>
-###Multi-Stage Authentication via request/response
-
-In applications that need to authenticate via multiple mechanisms (e.g. multi-factor authentication), a Request/Response protocol for login would probably be easier to use to support such workflows. For example:
-
-``` java
-LoginRequest request = //create login request
-LoginResponse response = subject.login(request);
-if (!response.isComplete()) {
- LoginRequest secondRequest = response.nextRequest();
- //populate w/ data for 2nd phase
- response = subject.login(secondRequest);
-}
-if (response.hasException()) {
- throw response.getException();
-}
-...
-```
-
-Additionally probably change the Authenticator signature to be as follows:
-
-``` java
-AuthenticationResult authenticate(AuthenticationRequest) throws AuthenticationException;
-```
-
-<a name="Version2Brainstorming-CaptchaSupport"></a>
-###Captcha Support
-
-Captcha support would assist in human being verification (during login, during form submission, etc).
-
-<a name="Version2Brainstorming-Configurationperfilterinstanceandnopathmatching"></a>
-###Configuration per filter instance and no path matching
-
-<a name="Version2Brainstorming-filterperinstance"></a>
-[SHIRO-256](https://issues.apache.org/jira/browse/SHIRO-256) is opened for this and [Tynamo.org](http://tynamo.org) already has an implementation for it. This would both simplify the filter logic and result in better performance.
-
-<a name="Version2Brainstorming-Webmodulerepackaging."></a>
-###Web module repackaging.
-
-The Web module is largely Servlet-specific at the moment. As such, its packaging should reflect this, in the same way that all other support modules are named, e.g.
-module name: `shiro-servlet`
-package base: `org.apache.shiro.servlet.*`
-<input type="hidden" id="ghEditPage" value="version-2-brainstorming.md"></input>
diff --git a/wiki-todos.md b/wiki-todos.md
deleted file mode 100644
index 8833c8d..0000000
--- a/wiki-todos.md
+++ /dev/null
@@ -1,13 +0,0 @@
-<a name="WikiTodos-WikiTodos"></a>
-#Wiki Todos
-
-- Authentication Guide
-- Authorization Guide
-- Session Management Guide
-- Cryptography Guide
-- Terminology Page
- - Group terminology for easier reading
- - Add more terminology where needed
-
-Complete Reference Manual
-<input type="hidden" id="ghEditPage" value="wiki-todos.md"></input>