You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by ad...@apache.org on 2014/11/14 16:28:51 UTC
svn commit: r1639671 - in
/wicket/common/site/trunk/_site/guide/guide/src/docs/guide:
security/security_3.gdoc security/security_5.gdoc security/security_6.gdoc
urls/urls_6.gdoc
Author: adelbene
Date: Fri Nov 14 15:28:51 2014
New Revision: 1639671
URL: http://svn.apache.org/r1639671
Log:
Changes for WICKET-5756
Added:
wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_6.gdoc
Modified:
wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_3.gdoc
wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_5.gdoc
wicket/common/site/trunk/_site/guide/guide/src/docs/guide/urls/urls_6.gdoc
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_3.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_3.gdoc?rev=1639671&r1=1639670&r2=1639671&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_3.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_3.gdoc Fri Nov 14 15:28:51 2014
@@ -4,7 +4,7 @@ HTTPS is the standard technology adopted
In Wicket we can easily protect our pages with HTTPS mounting a special request mapper called @HttpsMapper@ and using annotation RequireHttps with those pages we want to serve over this protocol. Both these two entities are in package @org.apache.wicket.protocol.https@.
-HttpsMapper wraps an existing mapper and redirects incoming requests to HTTPS if the related response must render a page containing annotation @RequireHttps@. Most of the times the wrapped mapper will be the root one, just like we saw before for @CryptoManager@ in paragraph 10.6.
+HttpsMapper wraps an existing mapper and redirects incoming requests to HTTPS if the related response must render a page containing annotation @RequireHttps@. Most of the times the wrapped mapper will be the root one, just like we saw before for @CryptoMapper@ in paragraph 10.6.
Another parameter needed to build a @HttpsMapper@ is an instance of class @HttpsConfi@g. This class allows us to specify which ports must be used for HTTPS and HTTP. By default the port numbers used by these two protocols are respectively 443 and 80.
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_5.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_5.gdoc?rev=1639671&r1=1639670&r2=1639671&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_5.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_5.gdoc Fri Nov 14 15:28:51 2014
@@ -1,14 +1,12 @@
+To encrypt/decryp page URLs Wicket uses an instance of interface @org.apache.wicket.util.crypt.ICrypt@:
+{code}
+public interface ICrypt
+{
+ String encryptUrlSafe(final String plainText);
+
+ String decryptUrlSafe(final String encryptedText);
+}
+{code}
- In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication.
-
-The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it.
-
-Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations.
-
-After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol.
-
-In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users.
-
-
-
+The default implementation for this interface
Added: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_6.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_6.gdoc?rev=1639671&view=auto
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_6.gdoc (added)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/security/security_6.gdoc Fri Nov 14 15:28:51 2014
@@ -0,0 +1,14 @@
+
+
+In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication.
+
+The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it.
+
+Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations.
+
+After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol.
+
+In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users.
+
+
+
Modified: wicket/common/site/trunk/_site/guide/guide/src/docs/guide/urls/urls_6.gdoc
URL: http://svn.apache.org/viewvc/wicket/common/site/trunk/_site/guide/guide/src/docs/guide/urls/urls_6.gdoc?rev=1639671&r1=1639670&r2=1639671&view=diff
==============================================================================
--- wicket/common/site/trunk/_site/guide/guide/src/docs/guide/urls/urls_6.gdoc (original)
+++ wicket/common/site/trunk/_site/guide/guide/src/docs/guide/urls/urls_6.gdoc Fri Nov 14 15:28:51 2014
@@ -185,13 +185,13 @@ Generated URL:
h3. Encrypting page URLs
-Sometimes URLs are a doubleâedged sword for our site because they can expose too many details about the internal structure of our web application and malicious users could exploit them to perform a "cross-site request forgery":http://en.wikipedia.org/wiki/Cross-site_request_forgery .
+Sometimes URLs are a doubleâedged sword for our site because they can expose too many details about the internal structure of our web application making it more vulnerable to malicious users.
-To avoid this kind of security threat we can use the CryptoMapper request mapper which wraps an existing mapper and encrypts the original URL producing a single encrypted segment:
+To avoid this kind of security threat we can use the @CryptoMapper@ request mapper which wraps an existing mapper and encrypts the original URL producing a single encrypted segment:
!url-encrypted.png!
-Typically, CryptoMapper is registered into a Wicket application as the root request mapper wrapping the default one:
+Typically, @CryptoMapper@ is registered into a Wicket application as the root request mapper wrapping the default one:
{code}
@Override
@@ -202,4 +202,8 @@ public void init() {
mountPage("/foo/", HomePage.class);
{code}
-As pointed out in the code above, pages and resources must be mounted after having set CryptoMapper as root mapper, otherwise the mounted paths will not work.
\ No newline at end of file
+As pointed out in the code above, pages and resources must be mounted after having set @CryptoMapper@ as root mapper, otherwise the mounted paths will not work.
+
+{warning}
+By default @CryptoMapper@ encrypts page URLs with a cipher that might not be strong enough for production environment. Paragraph 21.4 will provide a more detailed description of how Wicket encrypts page URLs and we will see how to use stronger ciphers.
+{warning}