Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T21:06:42Z

Chump Chief: /* External Links */

= Principle of Explicit Interfaces =

== Definition ==

The Principle of Explicit Interfaces is proposed by Bertrand Meyer in his book Object-Oriented Software Construction. It states

<blockquote>"Whenever two modules A and B communicate, this must be obvious from the text of A or B or both."</blockquote>

== Motivation ==

The Principle of Explicit Interfaces refers to the attempt to ensure that relationships between separate modules are easily found and understood. This is important when considering making a change to the code base. It allows the programmer to quickly see what other modules his work might impact, preventing unintended side effects.

Interaction between modules, either by direct manipulation or by shared data, is an example of [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling]. Coupling is a trait of object oriented software that should be avoided when possible, but when it is unavoidable the Principle of Explicit Interfaces should be used to make it as apparent as possible. This helps to reduce the impact that coupling may have.

== Application ==

One area in which it may be difficult to implement interfaces while adhering to the principle of explicit interfaces is shared data. Bertrand Meyer recognizes this problem and diagrams it as:

[[Image:Principle_of_Explicit_Interfaces_Data_Sharing.png]]

This illustrates how two modules may interact in an indirect manner. Although the two modules do not directly interact on each other, by relying on a common resource changes to module A may impact how module B functions.

== Relationship to Design by Contract ==

[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract] is another concept pioneered by Bertrand Meyer relating to the concept of having modules which act in well defined and predictable manners. This allows other modules to interact with them and get the results they expect.

Explicit interfaces is an important part of the contract, since it deals directly with interactions between modules being transparent and easy to spot. Knowing interactions between modules is essential when making a contract or guarantee for the implementing module's behavior.

== External Links ==

[http://www.cit.gu.edu.au/~francis/sa2000/unit2.htm#CRITERIA Notes on application architecture] - In addition to a summary of the principle of explicit interfaces, this site has information on Meyer's other principles, and some other important criteria for good application design.

[http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Object-Oriented Software Construction at Wikipedia] - For more information on the text in which the principle was introduced.

[http://se.ethz.ch/~meyer/ Bertrand Meyer's home page] - Find other publications and research by Meyer.

[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract at Wikipedia] - Other aspects of Design by Contract outside of the principle of explicit interfaces.

== Sources ==

*Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T21:05:14Z

Chump Chief: /* Relationship to Design by Contract */

= Principle of Explicit Interfaces =

== Definition ==

The Principle of Explicit Interfaces is proposed by Bertrand Meyer in his book Object-Oriented Software Construction. It states

<blockquote>"Whenever two modules A and B communicate, this must be obvious from the text of A or B or both."</blockquote>

== Motivation ==

The Principle of Explicit Interfaces refers to the attempt to ensure that relationships between separate modules are easily found and understood. This is important when considering making a change to the code base. It allows the programmer to quickly see what other modules his work might impact, preventing unintended side effects.

Interaction between modules, either by direct manipulation or by shared data, is an example of [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling]. Coupling is a trait of object oriented software that should be avoided when possible, but when it is unavoidable the Principle of Explicit Interfaces should be used to make it as apparent as possible. This helps to reduce the impact that coupling may have.

== Application ==

One area in which it may be difficult to implement interfaces while adhering to the principle of explicit interfaces is shared data. Bertrand Meyer recognizes this problem and diagrams it as:

[[Image:Principle_of_Explicit_Interfaces_Data_Sharing.png]]

This illustrates how two modules may interact in an indirect manner. Although the two modules do not directly interact on each other, by relying on a common resource changes to module A may impact how module B functions.

== Relationship to Design by Contract ==

[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract] is another concept pioneered by Bertrand Meyer relating to the concept of having modules which act in well defined and predictable manners. This allows other modules to interact with them and get the results they expect.

Explicit interfaces is an important part of the contract, since it deals directly with interactions between modules being transparent and easy to spot. Knowing interactions between modules is essential when making a contract or guarantee for the implementing module's behavior.

== External Links ==

[http://www.cit.gu.edu.au/~francis/sa2000/unit2.htm#CRITERIA Notes on application architecture] - In addition to a summary of the principle of explicit interfaces, this site has information on Meyer's other principles, and some other important criteria for good application design.

[http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Object-Oriented Software Construction at Wikipedia] - For more information on the text in which the principle was introduced.

[http://se.ethz.ch/~meyer/ Bertrand Meyer's home page] - Find other publications and research by Meyer.

== Sources ==

*Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T20:51:05Z

Chump Chief: added design by contract

= Principle of Explicit Interfaces =

== Definition ==

The Principle of Explicit Interfaces is proposed by Bertrand Meyer in his book Object-Oriented Software Construction. It states

<blockquote>"Whenever two modules A and B communicate, this must be obvious from the text of A or B or both."</blockquote>

== Motivation ==

The Principle of Explicit Interfaces refers to the attempt to ensure that relationships between separate modules are easily found and understood. This is important when considering making a change to the code base. It allows the programmer to quickly see what other modules his work might impact, preventing unintended side effects.

Interaction between modules, either by direct manipulation or by shared data, is an example of [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling]. Coupling is a trait of object oriented software that should be avoided when possible, but when it is unavoidable the Principle of Explicit Interfaces should be used to make it as apparent as possible. This helps to reduce the impact that coupling may have.

== Application ==

One area in which it may be difficult to implement interfaces while adhering to the principle of explicit interfaces is shared data. Bertrand Meyer recognizes this problem and diagrams it as:

[[Image:Principle_of_Explicit_Interfaces_Data_Sharing.png]]

This illustrates how two modules may interact in an indirect manner. Although the two modules do not directly interact on each other, by relying on a common resource changes to module A may impact how module B functions.

== Relationship to Design by Contract ==

== External Links ==

[http://www.cit.gu.edu.au/~francis/sa2000/unit2.htm#CRITERIA Notes on application architecture] - In addition to a summary of the principle of explicit interfaces, this site has information on Meyer's other principles, and some other important criteria for good application design.

[http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Object-Oriented Software Construction at Wikipedia] - For more information on the text in which the principle was introduced.

[http://se.ethz.ch/~meyer/ Bertrand Meyer's home page] - Find other publications and research by Meyer.

== Sources ==

*Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T20:50:13Z

Chump Chief: /* Definition */

= Principle of Explicit Interfaces =

== Definition ==

The Principle of Explicit Interfaces is proposed by Bertrand Meyer in his book Object-Oriented Software Construction. It states

<blockquote>"Whenever two modules A and B communicate, this must be obvious from the text of A or B or both."</blockquote>

== Motivation ==

The Principle of Explicit Interfaces refers to the attempt to ensure that relationships between separate modules are easily found and understood. This is important when considering making a change to the code base. It allows the programmer to quickly see what other modules his work might impact, preventing unintended side effects.

Interaction between modules, either by direct manipulation or by shared data, is an example of [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling]. Coupling is a trait of object oriented software that should be avoided when possible, but when it is unavoidable the Principle of Explicit Interfaces should be used to make it as apparent as possible. This helps to reduce the impact that coupling may have.

== Application ==

One area in which it may be difficult to implement interfaces while adhering to the principle of explicit interfaces is shared data. Bertrand Meyer recognizes this problem and diagrams it as:

[[Image:Principle_of_Explicit_Interfaces_Data_Sharing.png]]

This illustrates how two modules may interact in an indirect manner. Although the two modules do not directly interact on each other, by relying on a common resource changes to module A may impact how module B functions.

== External Links ==

[http://www.cit.gu.edu.au/~francis/sa2000/unit2.htm#CRITERIA Notes on application architecture] - In addition to a summary of the principle of explicit interfaces, this site has information on Meyer's other principles, and some other important criteria for good application design.

[http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Object-Oriented Software Construction at Wikipedia] - For more information on the text in which the principle was introduced.

[http://se.ethz.ch/~meyer/ Bertrand Meyer's home page] - Find other publications and research by Meyer.

== Sources ==

*Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T20:36:44Z

Chump Chief: /* Motivation */

= Principle of Explicit Interfaces =

== Definition ==

The Principle of Explicit Interfaces is proposed by Bertrand Meyer in his book Object-Oriented Software Construction. It states

<blockquote>Whenever two modules A and B communicate, this must be obvious from the text of A or B or both.</blockquote>

== Motivation ==

The Principle of Explicit Interfaces refers to the attempt to ensure that relationships between separate modules are easily found and understood. This is important when considering making a change to the code base. It allows the programmer to quickly see what other modules his work might impact, preventing unintended side effects.

Interaction between modules, either by direct manipulation or by shared data, is an example of [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 coupling]. Coupling is a trait of object oriented software that should be avoided when possible, but when it is unavoidable the Principle of Explicit Interfaces should be used to make it as apparent as possible. This helps to reduce the impact that coupling may have.

== Application ==

One area in which it may be difficult to implement interfaces while adhering to the principle of explicit interfaces is shared data. Bertrand Meyer recognizes this problem and diagrams it as:

[[Image:Principle_of_Explicit_Interfaces_Data_Sharing.png]]

This illustrates how two modules may interact in an indirect manner. Although the two modules do not directly interact on each other, by relying on a common resource changes to module A may impact how module B functions.

== External Links ==

[http://www.cit.gu.edu.au/~francis/sa2000/unit2.htm#CRITERIA Notes on application architecture] - In addition to a summary of the principle of explicit interfaces, this site has information on Meyer's other principles, and some other important criteria for good application design.

[http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction Object-Oriented Software Construction at Wikipedia] - For more information on the text in which the principle was introduced.

[http://se.ethz.ch/~meyer/ Bertrand Meyer's home page] - Find other publications and research by Meyer.

== Sources ==

*Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T09:22:34Z

Chump Chief: /* External Links */

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T09:15:43Z

Chump Chief: /* Application */

File:Principle of Explicit Interfaces Data Sharing.png

2009-11-18T09:11:47Z

Chump Chief: Diagram showing the challenge of the Principle of Explicit Interfaces. Source: Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

Diagram showing the challenge of the Principle of Explicit Interfaces.

Source: Meyer, Bertrand. Object-Oriented Software Construction, 2nd edition p50. ISE Inc., Santa Barbara, CA, 1997.

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T09:06:46Z

Chump Chief: /* Motivation */

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T07:50:16Z

Chump Chief: /* Sources */

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T07:49:59Z

Chump Chief: added definition

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-18T07:23:29Z

Chump Chief: added sections

= Principle of Explicit Interfaces =

== Definition ==

== Motivation ==

== Application ==

== External Links ==

== Sources ==

CSC/ECE 517 Fall 2009/wiki3 13 b5

2009-11-17T05:16:36Z

Chump Chief: creating the page

== Principle of Explicit Interfaces ==

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T02:10:20Z

Chump Chief: /* Overview */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. These types of actions could produce unpredictable results and must be protected against.

For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. In this example it might result in the client's account being charged multiple times, or multiple orders being shipped which aren't charged, etc.

A client could also click their back button after submitting the form, or refresh the page. In addition to the problems caused by multiple clicks, this could also cause an attempt to access data that no longer exists (e.g. credit card number purged from system after transaction completed). Depending on how robust the system is, this could cause other unpredictable results.

Finally, the client might have malicious intent and be trying to subvert the site. By exploiting desynchronization between the client and server the client may be able to perform actions they should not. A good example is an online poll. By clicking multiple times on a vote button very quickly before the vote is processed, the client may be able to get multiple votes in before the system realizes they are stuffing the ballot box.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

The control flow diagram below depicts the synchronizer token pattern working with a valid token (normal usage):

[[Image:Positive_flow.png]]

The control flow diagram below depicts the synchronizer token pattern working with an invalid token (erroneous usage):

[[Image:Negative_flow.png]]

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and reset(HttpServletRequest req) which create, validate, and destroy tokens, respectively. resetToken(HttpServletRequest req) may also be used to destroy the token.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

File:Negative flow.png

2009-10-10T02:09:40Z

Chump Chief: Depicting synchronizer token pattern control flow with an invalid token.

Depicting synchronizer token pattern control flow with an invalid token.

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T02:08:48Z

Chump Chief: /* Overview */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. These types of actions could produce unpredictable results and must be protected against.

For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. In this example it might result in the client's account being charged multiple times, or multiple orders being shipped which aren't charged, etc.

A client could also click their back button after submitting the form, or refresh the page. In addition to the problems caused by multiple clicks, this could also cause an attempt to access data that no longer exists (e.g. credit card number purged from system after transaction completed). Depending on how robust the system is, this could cause other unpredictable results.

Finally, the client might have malicious intent and be trying to subvert the site. By exploiting desynchronization between the client and server the client may be able to perform actions they should not. A good example is an online poll. By clicking multiple times on a vote button very quickly before the vote is processed, the client may be able to get multiple votes in before the system realizes they are stuffing the ballot box.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

The control flow diagram below depicts the synchronizer token pattern working with a valid token (normal usage):

[[Image:Positive_flow.png]]

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and reset(HttpServletRequest req) which create, validate, and destroy tokens, respectively. resetToken(HttpServletRequest req) may also be used to destroy the token.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

File:Positive flow.png

2009-10-10T02:07:05Z

Chump Chief: Depicting synchronizer token pattern control flow with a valid token.

Depicting synchronizer token pattern control flow with a valid token.

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:50:34Z

Chump Chief: /* Java (with Struts) */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. These types of actions could produce unpredictable results and must be protected against.

For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. In this example it might result in the client's account being charged multiple times, or multiple orders being shipped which aren't charged, etc.

A client could also click their back button after submitting the form, or refresh the page. In addition to the problems caused by multiple clicks, this could also cause an attempt to access data that no longer exists (e.g. credit card number purged from system after transaction completed). Depending on how robust the system is, this could cause other unpredictable results.

Finally, the client might have malicious intent and be trying to subvert the site. By exploiting desynchronization between the client and server the client may be able to perform actions they should not. A good example is an online poll. By clicking multiple times on a vote button very quickly before the vote is processed, the client may be able to get multiple votes in before the system realizes they are stuffing the ballot box.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and reset(HttpServletRequest req) which create, validate, and destroy tokens, respectively. resetToken(HttpServletRequest req) may also be used to destroy the token.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:47:13Z

Chump Chief: /* Problem summary */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. These types of actions could produce unpredictable results and must be protected against.

For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. In this example it might result in the client's account being charged multiple times, or multiple orders being shipped which aren't charged, etc.

A client could also click their back button after submitting the form, or refresh the page. In addition to the problems caused by multiple clicks, this could also cause an attempt to access data that no longer exists (e.g. credit card number purged from system after transaction completed). Depending on how robust the system is, this could cause other unpredictable results.

Finally, the client might have malicious intent and be trying to subvert the site. By exploiting desynchronization between the client and server the client may be able to perform actions they should not. A good example is an online poll. By clicking multiple times on a vote button very quickly before the vote is processed, the client may be able to get multiple votes in before the system realizes they are stuffing the ballot box.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and resetToken(HttpServletRequest req) which create, validate, and destroy tokens, respectively.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:37:09Z

Chump Chief:

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and resetToken(HttpServletRequest req) which create, validate, and destroy tokens, respectively.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:36:34Z

Chump Chief: /* Java (with Struts) */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and resetToken(HttpServletRequest req) which create, validate, and destroy tokens, respectively.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]:

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:36:26Z

Chump Chief: /* Java (with Struts) */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and resetToken(HttpServletRequest req) which create, validate, and destroy tokens, respectively.

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:35:50Z

Chump Chief: /* Example application */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

=== Java (with Struts) ===

From [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

The key methods in this implementation are saveToken(HttpServletRequest req), isTokenValid(HttpServletRequest req), and resetToken(HttpServletRequest req) which create, validate, and destroy tokens, respectively.

=== Ruby on Rails ===

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:32:44Z

Chump Chief: /* Example application */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java (with Struts) from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:28:16Z

Chump Chief: /* Example application */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

A synchronizer token pattern could be easily implemented in Ruby on Rails by using before_filter and after_filter to perform token creation and invalidation at the appropriate times (create token before displaying the form page, invalidate token after taking the submit action).

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:24:22Z

Chump Chief: /* Resources */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.corej2eepatterns.com/Design/PresoDesign.htm Core J2EE Patterns]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:19:24Z

Chump Chief:

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

== Other solutions ==

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:18:20Z

Chump Chief: /* Critique */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

== Critique ==

Use of this pattern requires the programmer to consider another alternative flow for if the token is invalid. Depending on the design decisions made this may complicate the program. For example, if the user tries to submit a large amount of form data with an invalid token, the designer might want to preserve their entries while issuing a new token. Failure to preserve entries might cause a user to give up and not follow through with their action on the site. However, this is an additional feature that must then be designed, added, and tested.

The common alternative to the synchronizer token pattern is to simply use Javascript or similar to disable the "submit" button on the client side. This solves the issue of multiple clicks on the button without the need for an alternative program flow. However, this is less reliable since the user might still use their back button or a bookmark to revisit the page.

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:08:20Z

Chump Chief: /* Example application */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 Java World]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:08:09Z

Chump Chief: /* Example application */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

Java from [http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=2 JavaWorld]

<blockquote><pre>
public final ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
HttpSession session = request.getSession();
ActionForward forward = null;
if (isTokenValid(request)) {
// Reset token and session attributes
reset(request);
try {
// Perform the action and store the results
forward = performSynchro(mapping, form, request, response);
session.setAttribute(FORM_KEY, form);
session.setAttribute(FORWARD_KEY, forward);
ActionErrors errors = (ActionErrors)
request.getAttribute(Action.ERROR_KEY);
if (errors != null && !errors.empty()) {
saveToken(request);
}
session.setAttribute(ERRORS_KEY, errors);
session.setAttribute(COMPLETE_KEY, "true");
} catch (IOException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
} catch (ServletException e) {
// Store and rethrow the exception
session.setAttribute(EXCEPTION_KEY, e);
session.setAttribute(COMPLETE_KEY, "true");
throw e;
}
} else {
// If the action is complete
if ("true".equals(session.getAttribute(COMPLETE_KEY))) {
// Obtain the exception from the session
Exception e = (Exception) session.getAttribute(EXCEPTION_KEY);
// If it is not null, throw it
if (e != null) {
if (e instanceof IOException) {
throw (IOException) e;
} else if (e instanceof ServletException) {
throw (ServletException) e;
}
}
// Obtain the form from the session
ActionForm f = (ActionForm) session.getAttribute(FORM_KEY);
// Set it in the appropriate context
if ("request".equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), f);
} else {
session.setAttribute(mapping.getAttribute(), f);
}
// Obtain and save the errors from the session
saveErrors(request, (ActionErrors)
session.getAttribute(ERRORS_KEY));
// Obtain the forward from the session
forward = (ActionForward) session.getAttribute(FORWARD_KEY);
} else {
// Perform the appropriate action in case of token error
forward = performInvalidToken(mapping, form, request, response);
}
}
return forward;
}
</pre></blockquote>

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:02:59Z

Chump Chief: /* Resources */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:01:33Z

Chump Chief: /* Resources */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136] 
[http://www.coderanch.com/t/51602/Struts/Duplicate-form-submission-Synchronizer-Token Code Ranch]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T01:01:18Z

Chump Chief: /* Resources */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]
[http://www.coderanch.com/t/51602/Struts/Duplicate-form-submission-Synchronizer-Token Code Ranch]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T00:54:00Z

Chump Chief: /* Overview */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

The Synchronizer Token pattern is a server side solution to this problem. The concept is fairly simple: Establish a token on the server side that indicates a valid submission, and give a token signature to the client that corresponds to that token (most likely in a hidden input field). When the client submits their form, the server validates their token and proceeds. It then marks the token as invalid so it may not be used again. The result is that any given form may only be used once and then will not work again.

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T00:45:07Z

Chump Chief: /* Problem summary */

= Synchronizer Token Pattern =

== Problem summary ==

Many websites rely on synchronous activity between the client and server. This synchronization can be disrupted if the client takes actions in an order not expected by the server. For instance, when submitting a purchase in an online store, the client might click the "Purchase" button multiple times. They might hit their browser's back button and take another action while the transaction is still processing. These types of actions could produce unpredictable results and must be protected against.

== Overview ==

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-10T00:34:07Z

Chump Chief: /* Resources */

= Synchronizer Token Pattern =

== Problem summary ==

== Overview ==

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

[http://www.javaworld.com/javaworld/javatips/jw-javatip136.html Java World Tip 136]

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-09T20:34:02Z

Chump Chief: Possible layout

= Synchronizer Token Pattern =

== Problem summary ==

== Overview ==

== Example application ==

== Critique ==

== Other solutions ==

== Further reading ==

== Resources ==

CSC/ECE 517 Fall 2009/wiki2 3 b5

2009-10-09T20:30:26Z

Chump Chief: Getting started

= Synchronizer Token Pattern =

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-28T02:25:44Z

Chump Chief: /* Other Libraries of Interest */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.ruby-lang.org/en/ The Ruby Homepage] ===
The main page for the Ruby language provides the installation files, documentation, and useful resources. Also, for any questions not answered by the following resources you can try the Community tab. There you'll find a list of Ruby community sites where you can get additional support and information.

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Debugging ==

=== [http://rubyforge.org/projects/ruby-debug/ ruby-debug] ===
ruby-debug allows for easy command line debugging, which is helpful for those of us who still cling to text editors. The screencast available at [http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/ this location] does an excellent overview of what ruby-debug can do.

=== [http://www2.aptana.com/docs/index.php/Ruby_Debugger Aptana] ===
This is the Aptana documentation on using the ruby-debug-ide gem with Eclipse. It provides step by step images depicting a debug session.

== Other Libraries of Interest ==

=== [http://hanklords.github.com/flickraw/ Flickraw] ===
Flickraw provides a Ruby interface to the Flickr API. The Flickr API allows many operations like search, photo upload, and creation of photosets.

=== [http://twitter.rubyforge.org/ Twitter] ===
The Twitter Ruby gem provides a Ruby interface to the Ruby API. Similar to Flickraw, this gem allows the common Twitter operations to be executed in a Ruby environment.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-28T01:28:54Z

Chump Chief:

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.ruby-lang.org/en/ The Ruby Homepage] ===
The main page for the Ruby language provides the installation files, documentation, and useful resources. Also, for any questions not answered by the following resources you can try the Community tab. There you'll find a list of Ruby community sites where you can get additional support and information.

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Debugging ==

=== [http://rubyforge.org/projects/ruby-debug/ ruby-debug] ===
ruby-debug allows for easy command line debugging, which is helpful for those of us who still cling to text editors. The screencast available at [http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/ this location] does an excellent overview of what ruby-debug can do.

=== [http://www2.aptana.com/docs/index.php/Ruby_Debugger Aptana] ===
This is the Aptana documentation on using the ruby-debug-ide gem with Eclipse. It provides step by step images depicting a debug session.

== Other Libraries of Interest ==

=== [http://hanklords.github.com/flickraw/ Flickraw] ===
Flickraw provides a Ruby interface to the Flickr API. The Flickr API allows many operations like search, photo upload, and creation of photosets.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-28T00:30:52Z

Chump Chief: /* Language Resources */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.ruby-lang.org/en/ The Ruby Homepage] ===
The main page for the Ruby language provides the installation files, documentation, and useful resources. Also, for any questions not answered by the following resources you can try the Community tab. There you'll find a list of Ruby community sites where you can get additional support and information.

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Debugging ==

=== [http://rubyforge.org/projects/ruby-debug/ ruby-debug] ===
ruby-debug allows for easy command line debugging, which is helpful for those of us who still cling to text editors. The screencast available at [http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/ this location] does an excellent overview of what ruby-debug can do.

=== [http://www2.aptana.com/docs/index.php/Ruby_Debugger Aptana] ===
This is the Aptana documentation on using the ruby-debug-ide gem with Eclipse. It provides step by step images depicting a debug session.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T07:10:58Z

Chump Chief: /* Debugging */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Debugging ==

=== [http://rubyforge.org/projects/ruby-debug/ ruby-debug] ===
ruby-debug allows for easy command line debugging, which is helpful for those of us who still cling to text editors. The screencast available at [http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/ this location] does an excellent overview of what ruby-debug can do.

=== [http://www2.aptana.com/docs/index.php/Ruby_Debugger Aptana] ===
This is the Aptana documentation on using the ruby-debug-ide gem with Eclipse. It provides step by step images depicting a debug session.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:59:01Z

Chump Chief: /* Resources for Ruby (other than IDEs) */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Debugging ==

=== [http://rubyforge.org/projects/ruby-debug/ ruby-debug] ===
ruby-debug allows for easy command line debugging, which is helpful for those of us who still cling to text editors. The screencast available at [http://brian.maybeyoureinsane.net/blog/2007/05/07/ruby-debug-basics-screencast/ this location] does an excellent overview of what ruby-debug can do.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:45:49Z

Chump Chief: /* Useful Gems */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===
The Little Book of Ruby is an introduction to Ruby that quickly gets you started with Ruby programming. At only 90 pages (.pdf) and using simple, clear language, it's a very quick read. It assumes the reader has prior programming experience, though not necessarily in an object oriented language. All of the code used in the book is also available online.

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===
The tutorial on RubyLearning provides more and larger code samples than the Little Book of Ruby. It also covers a few more niche topics. In particular note the "summary" pages, which provide a quick checklist of topics covered in the preceding sections. Skimming the summary pages will let you quickly decide if there's any new material to learn without having to read the whole thing. The direct link to the tutorial is [http://rubylearning.com/satishtalim/tutorial.html here].

== Testing ==

=== [http://cukes.info/ Cucumber] ===
Cucumber allows black box tests to be written in plain English, making test documentation and comprehension much easier. It also inherently promotes evaluation of the business value of the things you are testing, which is always a good idea.

=== [http://wtr.rubyforge.org/ Watir] ===
Watir and its sister projects give you hooks into various web browsers for web based black box testing. Alternatively, [http://celerity.rubyforge.org/ Celerity] allows testing without requiring a browser, which results in faster, platform independent tests.

== Ruby Projects ==

=== [http://rubyforge.org/ RubyForge] ===
RubyForge is basically SourceForge for only Ruby based projects. Learn about Ruby and Ruby development by seeing actual applications of the language, or contribute your own knowledge to a project.

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:41:12Z

Chump Chief: /* Useful Gems */

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:31:50Z

Chump Chief: /* Resources for Ruby (other than IDEs) */

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:10:39Z

Chump Chief: /* Plugins */

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T06:03:05Z

Chump Chief: /* Language Resources */

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T05:54:50Z

Chump Chief: /* Language Resources */

CSC/ECE 517 Fall 2009/wiki1b 7 b5

2009-09-21T05:44:00Z

Chump Chief: /* Language Resources */

= Resources for Ruby (other than IDEs) =

== Language Resources ==

=== [http://www.sapphiresteel.com/The-Little-Book-Of-Ruby The Little Book of Ruby] ===

=== [http://www.zenspider.com/Languages/Ruby/QuickRef.html Ruby QuickRef] ===
Ruby QuickRef is an excellent resource for quickly looking up Ruby syntax. Rather than giving paragraphs of explanation and loads of examples, it simply provides the syntax in a well sectioned and easy to read format. Think of it as a Ruby cheat sheet.

=== [http://rubylearning.com/ RubyLearning] ===

== Plugins ==

=== [http://rubyforge.org/ RubyForge] ===